"Copy file or Folder" action give the "Invalid path" error when there is a build variable in either source or destination file path.
E.g "D:\TfsDeployments\$(BuildNumber)". It's working fine for static path.
Does anyone know how the variable can be used in file path for copy purpose?
Thanks in advance.
Variables only work with components, not with actions. This is because you can use Release Management without tying a release template to a particular build definition. What would $(BuildNumber) if there was no related build?
Related
I am trying to replicate one coding example in Visual Studio and I see that in a form there are some resx files.
I am trying to put a resx file into my form as well so I created a new resource file but as I try to move it on the form in solution explorer i get an error saying i cannot do that ("destination folder is the same as the origin")
I am new to Visual Basic so maybe I am missing something but where am I doing wrong?
Rename the copy of folder and files because two folders with same name can not exist at same place.
Copy file to outside anyway rename and again paste there.
We are facing situation when some developers modify the project file (*.sqlproj) for example by adding or removing objects, then they do not save all the files in the Visual Studio and try to commit/push changes using command line. In that case the *.sqlproj file is not saved yet and it is not caught by the git. There is no problems when you commit/push from Visual Studio as it warns you that you have not saved files and asks you what to do.
So the question... Is there a way to find that the file is modified, but not saved yet? Maybe there are some temp files location or any other proper way of doing that?
I've packaged my WinForms app with the Visual Studio Installshield Limited Edition wizard.
When installing the app, I get this error during installation.
Error 2715. The specified File key ('myappname.xml_serializa') not found in the File table
Any ideas from anyone? I'm completely loss on this one.
In your installer project directory, open the *.isl file and search for the text in your error message, myappname.xml_serializa. It will most likely be in there quite a few times. Either remove it or correct all instances of it.
I had a similar problem recently and found out that it didn't find the key because I was not adding the .primaryoutput file on the section Specify Application Data -> Files. Check if you are adding all the necessary files for your setup before creating the installer. The installer will be created even if it doesn't have all the files, but it won't execute properly.
Hope this helps
Changing the *.isl file resolved our issue. I found that we had changed the .NET framework of a project and when we removed the project output from the Installshield using the prompt it did not update this file so when we added the output again it now contained two outputs. OUTPUT and OUTPUT1. Hope this helps
This is what worked for me: The project in my case was readonly as it was connected to TFS. If you are working offline, make sure you make the project files writable. (Uncheck Read Only at the folder level)
This worked for me:
In your setup project double-click Project Assistant.
Click on Application Files.
Select file(s) with the file extension that was reported in the error message(s).
Click on Delete.
Repeat for any files as needed.
Go back to setup project in Solution Explorer.
Click on Rebuild
I have the following situation:
WPF Application
I know about the different ways of deploying. (CAO, InstallShield, ..)
Project includs some Report Files (.rdlc) which
are used by calling them via Path - Right now in a Subdirectory of my PRojectfolder
The Paths are defined in Settings
BUT:
I absolutely dont know how to handle this situation during and after Installation.
If I provide the rdlc files as additional files, how can I automatically change the path, after installation (so that the App can find them), because I dont know before the path of the new client machine. Or do I misunderstood an the InstallShield is managing this files and paths automatically!
Can anybody help me with the right strategy (I am not looking for Code)!?!?
Thanky in Advance
In the installer, place the files relative to INSTALLDIR directory. INSTALLDIR can be modified by the user during installation. You may want to save the value in a registry or a configuration file. For registry, create the required hive and key and set its value to [INSTALLDIR]. For configuration file, you would need to write a custom action that modifies the file with the chosen INSTALLDIR.
I am trying to make our SQL Server Integration Services packages as portable as possible and the one thing that is preventing that is that the path to the config is always an absolute path, which makes testing and deployment a headache. Are there any suggestions for making this more manageble?
Another issue is when another developer gets the package out of source control the path is specific to the developers machine.
If you are trying to execute your packages using Visual Studio then the configuration file path will be hardcoded in there. So if you move your project around you'll need to change the path in the package settings. To avoid this you could use the Environment variable option to store the configuration file path. Then you'll only need to change that.
For testing and deployment however you should probably use the dtexec utility to execute your packages. Make some batch files for that. Preferably one for each different environment. Here the configuration file path can be relative.
dtexec /File Package.dtsx /Conf configuration.dtsConfig
This is if you're packages are on file system. You can also store them in SQL Server. You can also store your configuration in SQL Server which may provide flexibility.
After several hours trying to make this work I found a solution here (not the best one, but it works)
Locate your configuration files (dtsconfig files) in the same directory as your solution file (.sln file)
ALWAYS open your solution by double-clicking the solution file (.sln file). This will set the ‘working folder’ to be where the solution lives, your configuration file will be read correctly
Otherwise the relative paths did not work for me.
Check out the free utility that can edit SSIS configuration file paths without BIDS:
http://ssisconfigeditor.codeplex.com/
My stock standard trick for these sorts of problems are mapping drives.
Either by using a mapped network drive or by using Subst (both methods are interchangable).
e.g. Map the location of your package to N:\ then inside your package use paths using N:\MyParentPackage.dtsx, N:\MyChildPackage.dtsx. The packages can be on totally different drives in different folders on different machines, it'll work once you map the package location to the N:\
I usually put a script along side the project files to map the drive, which maps the drive so it can be easily run before. One gotcha, if you're using subst on VISTA - Win8, map it for elevated and non-elevated.
I use the same approach for file references in Visual Studio projects. Only issue with this approach, you use to solve too many issues in your dev environment and you'll run out of drives letters.