When I add a file to my setup deployment project, Visual Studio won't allow me to edit the "SourcePath" to resolve an environment variable like $(DLL_PATH). It adds the file with the source path on my local machine and builds fine locally. When the same project is built on another machine, it won't work unless that machine also has the exact same path to files needed.
I want the SourcePath to resolve the $(DLL_PATH) so as long as a machine has it defined correctly the MSI package will build fine.
Not sure about the subst, since I have no control over what the other build machine looks like. If I try to assign a known directory to a virtual drive, it could possibly fail right?
Your best bet is to use subst.exe or a junction point to create a virtual directory. See here for information on junction points. Subst.exe simply creates a virtual drive letter. Put all of the deployable files in some directory tree with well-defined, constanct sub-paths, and make the root of that tree a junction point or virtual drive.
Actually what I did was setup a script.cmd to run after my project output is built to copy the dependencies to a folder that is relative to the actual project folder from the declared $(DLL_PATH). The setup project actually uses relative paths to the project, not absolute ones. So this works no matter what the build machine looks like. Then a script to remove this folder at the end.
Related
Is it possible include arbitrary files (in this case a .csv) from a TwinCAT project direct to the Boot directory of a PLC?
By using PATH_BOOTPATH in the file open/read FBs it is possible to load files from this directory in a convenient manner regardless of whether using a CE or Windows deployment, However deployment of files to this location seems to be the sticking point.
I know that a copy of the project code is included within the CurrentConfig<Project>.tpzip file, but this file is not easily accessible from code, or updateable.
I've found the 'Additional Files' section within the system configuration, but it makes little sense.
Adding a file from inside the project as a 'Relative' path doesn't seem to do anything
Adding a file from inside the project as an external path includes the file (via symbolic links?) in the 'CurrentConfig.tszip' file, which has the same issues as the .tpzip
Adding an external file as an external path again includes the file inside of the .tszip.
I'm willing to accept that this might not be possible, but it just feels odd that the PATH_BOOTPRJ and PATH_BOOTPATH roots are there and not accessing useful paths.
Deployment
To quote Beckhoff:
Deployment is used to set up commands that are to be executed during the installation and startup of an application.
The event types are essentially at what stage of the deployment process the command is performed, where the command can either be copying a file or execution of a script/program.
Haven't performed extensive testing but between absolute/relative pathing and execution this should solve nearly all issues with deployment configuration.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
I am working on some Eclipse projects that are stored on a USB key. I have added them to a workspace whose root folder is also on the USB key, but the projects are not located directly into this directory. As a result their absolute paths are written in the .projects folder of the workspace.
This raises problems when I use the key on several computers, because the drive letter assigned to the USB key is not always the same (and I do not want to assign a specific letter to it on all computers). Eclipse cannot open my projects when the drive letter differs from that of the USB key at the time I added the project to the workspace.
Is there a solution to this problem ? Specifically, is there a way to make Eclipse add projects to a workspace by using their relative path from the workspace folder ?
Its really not that hard. You just have to assign a new variable that points to WORKSPACE/..;. For example, you can use the Forge Minecraft modder pack - it has a workspace that is immediately ready no matter what machine downloads it, where you place it or even if you move it.
Download this:
http://files.minecraftforge.net/minecraftforge/minecraftforge-src-1.6.2-9.10.0.789.zip
And then unzip it and run install.bat/cmd. Then check the contents of forge/mcp/eclipse/Minecraft/{.project,.workspace} to see some examples.
I've got my workspace working on github like this.
In my experience it will break at some time if you try to "hack" the metadata of eclipse.
Consider the substcommand in windows (As you mention drive letter I assume windows)
create a bat file containing
subst N: .
Running this will mount the current dir as N: So You can place this on the usb drive, and run that prior to running eclipse, then You will always find the same content on drive N:
To remove the mount do
subst /D N:
You might consider making a bat file that mount N:, start eclipse and after eclipse exit unmount N: something like
startMyProject.bat:
subst N: .
N:/eclipse <yadayada options>
subst /D N:
The short answer is that you cannot do it without hacking your workspace metadata (under [workspace.dir]/.metadata). Eclipse workspaces aren't designed to be portable and even though you are not physically moving your workspace, you are in effect moving it by changing drive letters.
I'd recommend trying to find a way to have your projects under workspace.dir. Not guaranteed that you will not have problems that way, but may improve your odds. Depending on what features of Eclipse you use, you may very well end up with other types of absolute paths in your workspace metadata.
This question is kinda old, but there's an entirely different approach: You can create a Junction from the Folder where Eclipse expects the Project, for example E:\foo\workspace\myproject and link it to where the project lays, for example E:\bar\myproject.
A Junction essentially means that you can access the same folder through 2 different paths, thus you don't need to worry with the weird relative path limitations of Eclipse. To create it easily and fast, I recommend you to get Link Shell Extension
I haven't tried this myself, but this might work. Try:
Add your source folder as linked resource & remove previous definition:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-45.htm
Close eclipse and find your project folder in your workspace (ex: C:\Documents and Settings\username\workspace\yourproject\) Replace absolute paths in files .project & .classpath with relative paths.
I'm trying to port my entire 'workspace' to a USB key (including the Eclipse executable) so that I can carry my work anywhere with me and work off the key directly.
My directory hierarchy is similar to this:
/workspace/eclipse - Where my current eclipse binary is stored
/workspace/codebase - Where I keep the root of all my eclipse projects
/workspace/resources - Where I keep all project files (images, docs, libs, etc.)
It all works perfectly fine on one system. But when I change over to another system, the USB key gets mounted on another drive. For example, on my laptop, I get 'E:\', on my PC, I get 'K:\' and at work I get 'F:\', etc, etc.
This means that because Eclipse (for 'some' reason) seems to only use full path names (including driver letters) in every single one of its configuration files (such as .classpath), nothing ever works when I want to work on another system.
I put a 'libs' directory in the base of every project and populate it with its dependent JAR files. Why doesn't it use relative names instead, so that I could specify something like "../../libs/log4j.jar"?
Anyone know how to fix this problem? Does anyone know of a workaround for this?
Update: 2010.11.09
I've recently discovered Dropbox, which allows you to sync your files online and across your computers automatically with extreme ease. It includes 2GB of free space and you can upgrade to much more if you want (for a yearly fee).
I installed it on my two laptops, my two PC's, my Linux server and my Android phone and then I created a 'workspace' directory within the 'My Dropbox' folder. From the 'workspace' directory, I then installed Eclipse and created/configured all my projects as usual. I can literally work from any computer and everything always stays perfectly in sync. This is way better than any USB key functionality and its hassle!
Have you tried using Eclipse Portable?
The only thing to keep in mind is that when switching the workspace, you need to remember to give it a relative path (like ../../Data/workspace).
You could use the dos command subst to get a consistent drive letter by creating a new virtual drive letter (say x:) that maps to your Eclipse folder on your usb drive, and then make all the config paths reference the drive x:
You could make a little batch file on the usb drive that you click on to create the drive x:
C:\>help subst
Associates a path with a drive letter.
SUBST [drive1: [drive2:]path]
SUBST drive1: /D
drive1: Specifies a virtual drive to which you want to assign a path.
[drive2:]path Specifies a physical drive and path you want to assign to
a virtual drive.
/D Deletes a substituted (virtual) drive.
Type SUBST with no parameters to display a list of current virtual drives.
You could also remap letter for your USB stick in Windows Disk Management (subitem in Computer management) to be smth like 'U:'.
Once done, it will be re-assigned to same stick every time you plug it. Not very universal, since your user need rights to access this setting first time, but it could help in some different scenarios.
You can always use Ant to build your programs, with Ant you can have relative paths... Plus you can also use Ivy to track dependencies in Ant, I do that in every project that I have.
Another alternative is to manually edit your .classpath files to contain relative paths.
It is a bit of a hassle, though, as you'll have to manually update the files whenever Eclipse changes them.
We currently carry out development on a mapped drive. When I write nunit tests against a test assembly it will pick up the assembly, however does not recognise any of the tests.
If I move the solultion etc to a local drive and reference it again then everything works fine.
What I really woiuld like to know is why this is being caused, and how I can carry on using a network drive for development.
Per http://geekswithblogs.net/TimH/archive/2007/08/02/114340.aspx, NUnit apparently does not have appropriate permissions to access the assembly when on a network drive. The suggested fix is to add a post-build event to copy the assembly to a local temp directory and run NUnit off that copied assembly:
Within VS, open the project properties.
Go to the Build Events tab and enter the following 'Post-build event command line':
del /q c:\temp\nunit*.*
copy "$(TargetDir)." c:\temp\nunit
A potential issue you may have as a result of this change is related to the AppBase as per Unable to load <mytest> because it is not located under Appbase. The answer there is to update the Settings element within the .nunit file to include an app base of C:\Temp\NUnit then update the assembly element's path to remove any leading directory information.