Background:
I have about 170 SSIS packages. A new requirement is that users from other workstations can run them from their command lines using dtexec.
Question:
To make this possible I'd like to set change the protection level to encrypt sensitive with password, and change the password in each package.
Is there a way to automate this?
It's not something I've tried personally, but you could potentially amend or add the property in the XML source of the packages using a global search and replace.
A much easier method is to use the built in package configuration functionality. Configure your package to look to load its configuration from a config file. Distribute the config file with the package(s). You'll have to decide on what technique to use for the package to find it's config file (this technique will be used on all dev workstations). I've typically used registry entry. You can also use system variables. From an execution stand point, you can pass in the name and location of the config file to dtexec.
Related
I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.
I have a conversion issue. We have approximately 100 SSIS packages that were written with a hard coded SQL server name.
We have just been informed that the server name we currently use is changing to a new name. I am trying to find out if there is any tools, apps, Powershell scripts, et cetera that can be used to make this change without having to manually open up each package and make the changes. By the way, almost all the packages are encrypted.
How about using a config file to replace the connection string?
It won't matter what the hard-coded value currently is as the config will replace it.
Personally, I develop all packages to run in DEV (with a hard-coded server/file share reference), but apply a config when running through agent. That way when you promote packages from DEV to TEST and PROD all you have to do is update the config with the new conn string and file share location.
I am New to SSIS config side. I have created one package with its config file. My Project placed into my account folder at server. but I created the config file which I placed at shared drive folder and also copy the mypackage.dtsx file into another shared folder.
Now I have ran the package with dtexec.exe /f "mypackage.dtsx" without using config file even though it successfully run.
even I have changed some of the property into the config file and ran the package with use of the dtexec.exe command(mentioned above) and it was executed successfully.
So I have a question that, Do I need the config file at dtexec.exe command line because I can run my package by "dtexec.exe /f "mypackage.dtsx" " too?
I saw the syntax of dtexec.exe /f "package.dtsx" /config "myconfig.dtsconfig"
Please guide me...Does the package contains the config file and its changes?
The package will remember it's saved settings. The benefit of a config file is that if you need to override/shange the settings that are contained in it, you can do that without needing to open, fix, and redeploy your package. A config file is not ever necessary, it is just a convenience to you the developer, especially if your environment has a strict change management policy. It is usually easier to change values in a config than to edit and redeploy a package under strict change managment.
CLARIFICATION
It appears from your question that you may be thinking that when you change the config it will change your package regardless of including your config in your execution. All of the information from the config will be in the package at the time you save it, but it may differ from what is in the config. If you run without config, you are running exactly what is saved in the package. Package executions work like this:
Load package with all configurations from the saved .dtsx file
Check for configurations to load.
Load configuration in memory and overwrite values loaded from .dtsx package.
Execute.
This is simplified, and there are other things going on, but at the basic level this is accurate.
I am trying to use Nuget to distribute a ms build .targets file. I need to modify some elements of the file to include the installed path of a few assemblies. For that I would like to use the tools folder. I am having a hard time finding the token (if it exists) to do the replacement. Has anyone encountered this problem or know of a workaround?
http://docs.nuget.org/docs/creating-packages/configuration-file-and-source-code-transformations
You'll have to go the PowerShell route to get this done, as no transform exists AFAIK. The init.ps1 file can process some parameters provided by the NuGet VSIX.
Simply add the following to the top of the init.ps1 file and use the $installPath variable in your scripts that modify the file content.
param($installPath, $toolsPath, $package, $project)
Check here for an example usage.
I'm trying setup the Versioning bundle in RavenDB: http://ravendb.net/bundles/versioning
The installation instructions are pretty straight forward:
Simply place the Raven.Bundles.Versioning.dll in the Plugins
directory.
I've tried this do this by creating a "Plugins" directory under the Server directory (the Server directory contains the Raven.Server.exe), and dropping Raven.Client.Versioning.dll into that Plugins directory.
However, when I run RavenDB after that (either from the command line or as a service), it doesn't give me any indication that it has recognized the plugin, and when I save/edit new documents no versioning is being applied.
I've tried running with the default plugin directory settings (which supposedly automatically looks in the Plugins directory), and I've tried manually adding the PluginsDirectory setting to Raven.Server.exe.config, to no avail.
Has anyone been able to get plugins working, specifically the versioning bundle? Do you hae to do anything special?
Mike,
It is supposed to just work. Take a look at the statistics, you should see the versioning trigger registered there.
It is important to ensure that:
You are using the same version of the dlls
You restarts RavenDB after copying the directory
You don't reference another Raven/PluginsDirectory in the configuration
It is probably better to follow this up in the mailing list.
For Raven v2, you'll also add the bundle name to the the Raven/ActiveBundles property on a database document. The names should be semicolon-delimited.
For example, I have a database called MidwestAnimalRescue. To enable the Periodic Backup bundle and the Versioning bundle, my document will look like this: