Hi,
I have a multiple package solution that I've deployed using the manifest file produced with the development environment. If I need to make a change to a single package, how do I then deploy this package? Is it a case of rebuilding the entire solution and re-running the manifest file, or is there a simpler way?
Any help would be much appreciated, cheers.
Can't you just go into the bin folder of your solution and select the appropriate package then copy this to your desired location?|||I've experienced some strange behaviour doing this in the past that was solved by redeploying the entire solution using the deployment wizard. So I wasn't sure if there was something going on with the registry that I wasn't appreciating.
Are you confident that simply copying a modified package to the SSIS package store location will work consistently?
|||To be perfectly honest, I've never used the manifest or deployment utility. All I ever do is copy the package from the bin folder to my release folder. I then use the SQL package store and import from my release folder (although you can do this from your development directory, I like to keep one additional layer of last good build that I can reimport to the sql package store if worst comes to worst).
I do not believe that there is anything modified in the registry at any point in time during package deployment. I could very well be wrong, but from what I have read that is not the case. (NOTE: there is the possibility that you are using registry configurations, which you will need to set up in your new location)
-- From Microsoft SQL Server 2005 Integration Services by Kirk Haselden
"Integration Services provides a utility for moving packages, butfor a moment, let's take a step back and think about the deployment problem. What is it you're trying to accomplish? Is there something in the package, some setting or variable that can't be moved by simply copying the package to another machine? Not really. However, problems arise when you move a package that references external resources that are available on one machine that aren't available on another. For example, no amount of configuration magic is going to help if you attempt to run a package that references a custom task that isn't installed on the destination machine."
|||Ah, maybe that is the answer, simply use the Import option to load modified packages to the SSIS package store. Thanks for taking the time to reply, much appreciated.
No comments:
Post a Comment