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.
Related
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
I have an SSIS File System deployment and I am trying to understand if there is any easy way to deploy a large number of packages. The name implies that it is a physical directory on the disk, that I could copy/paste the files to, but I cannot find anything online that tells me where this directory lives.
Am I correct in thinking it works this way? Or will I need to either manually upload each package in SSMS or script an automated deployment
Your current files reside in:
\[your]\[computer]\pdevine\Documents\Visual Studio [yourVersion]\Projects
After creating a solution on the target, you can just copy and paste the files into the project directory for the target. If you don't know where to find your current files, click on any package and look here:
I have created a WPF application. I want to make installer file (exe) for this application.
This application also uses some other 3rd party files (bat files); which i have zipped.
I want to unzip this file while installing and set the path of unzipped dir in Path variable also.
I got a link http://www.msdotnet.co.in/2012/06/how-to-create-setup-fileexe-file-from.html#.U3GT7YGSzxp
which tells how to create a installer file.
How to achieve unzipped part and setting environment vairable while making installer?
Thanks
Take a look at wix from Microsoft.
It can be run standalone, but is great run from within visual studio. You write a small xml file detailing what you want installed, and it does the rest.
To run a zip command, use a CustomAction.
Search for Install-shield. It is old tool but having good scripting capability like what you are expecting (i.e) Unzipping the folder and dealing with path environment variable
Use Inno Setup (http://jrsoftware.org/isinfo.php) or NSIS (http://nsis.sourceforge.net/Main_Page).
Both are free (open source) installation systems with many possibilities and huge community around (even here on SO).
They are really easy to use (especially Inno) and they are powerful so it is easy to achieve your required functionality.
Take a look at Stall:
https://github.com/jamesqo/Stall
It's an OSS project that lets you install your app from the command line, no configuration required.
Example Usage:
stall path/to/YourApp -e YourApp.exe -i YourApp.exe
This installs your app straight to the user's computer without having to make an intermediary MSI.
If you have to unzip files as well, you may want to just consider a simple batch files that downloads the binaries + unzips the contents + runs Stall.
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'm currently rebuilding all our setup files (used to be .exe files) into MSI installers so that I can deploy them through Active Directory.
Basically, we have a tool (Windev for those who know it) that generates MSI files, but since our tool is limited, I generate .mst files (using Orca) to fine-tune the setup, and merge the source installer and the transform with msitran.exe. When I manually install the transformed setup file with /qb or /qn, the install works fine.
But when I try to add the setup file in the AD, I get an error message : "Unable to extract deployment information".
I found multiple solutions online, but none of them fit my problem (ie. I have all admin rights, my final MSI validates in Orca (with a couple warnings, but no errors). I get the same issue with the original MSI that our tool generates (but it doesn't validate in ORCA, hence the transform to fix that among other things).
Are there any properties that I need to set to successfully deploy my MSI to AD ?
Never mind, solution is plain stupid, but MS does not mention this anywhere.
Basically, it was an issue with the UNC path. My MSI was located in a path that contained whitespaces, and Windows Server 2003 apparently doesn't like that (wrapping the path in quotes in the open dialog does not change anything). Moving the files to a path without spaces fixed it.
Good day to all