I am using Azure Devops in my project which means my SSIS project is stored in a file location that looks like this: C:\Users\johan\source\repos\Data Warehouse\Scripts. We are using the Project Deployment model.
In Visual Studio configuration manager I would like to make the DEV configuration dependent on the user. So for André this would change into C:\Users\andre\source\repos\Data Warehouse\Scripts and for Kasper into C:\Users\kasper\source\repos\Data Warehouse\Scripts. This would allow developers to run a changed script directly from Visual Studio. I could also have a fixed folder with scripts somewhere, but in that case a developer must copy his changed script to this folder to make it work.
I know parameters can't be variable but is there any other way to make this location dependent on the current user? These scripts are for example Powershell scripts that are executed from a package.
Related
I have a 3rd party library which loads configuration from app.config
Now I want to configure it via Azure Service Fabric
Using the standard settings.xml will require a lot of work.
Instead I'm hoping to simply copy the old app.config into the SF Config folder and load configuration from there.
Basically the only thing I could not figure out is how to know the path of where the Config/* contents will be while running in SF.
I can get Context.CodePackageActivationContext.WorkDirectory
However, then the path from that is
..\MyClass.ServicePkg.Config.1.0.0\app.config
Is there a path I can query on the Context somehow to get full path to config folder?
Yeah you can get the absolute path to your Code and Config packages, substituting the names of your packages ("Code" and "Config" are the default names in the Visual Studio project templates):
string codePackagePath = this.Context.CodePackageActivationContext.GetCodePackageObject("Code").Path;
string configPackagePath = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config").Path;
Some background info on service packaging here.
tl;dr:
Services are composed of "code" packages (your executables and DLLs) and "config" packages (any arbitrary configuration file or the built-in Settings.xml). Packages can be versioned and upgraded independently of each other. You can see this in Service Fabric Explorer under the "Details" tab of an application type (note the "Name" field - you can use any name you want and that's the name you put in GetCodePackageObject()).
I've been working with SSIS reading different files - from CSVs to XLSXs - with no problems. My paths are relative, so SSIS searches for the files from the project's folder.
Well, today my colleague tried to run a package and he got a curious error message saying that the file could not be found under the "C:\windows\system32" folder. There's no configuration that would point SSIS to that folder and with me and a third colleague it's working well.
After some investigation we discovered that the problem has nothing to do with the user itself, but with how the user opens the project. Since the beginning I've been opening the project by double clicking the ".dtproj" file. My colleague first opens the SSIS development interface then opens the project file from the menu.
Has anyone noticed that behavior? What could be the cause for that?
error message print
Microsoft Visual Studio 2008
Version 9.0.30729.4462 QFE
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: IDE Standard
This happens because the different ways of launching the IDE end up with different current directories for the IDE process. You can test this by creating a package with only a Script Task, with the one line:
MessageBox.Show(Environment.CurrentDirectory);
And then running this project after launching it both ways.
Double-clicking the project or solution file sets the folder containing that file as the current directory. (I assume this is standard Windows process launching behaviour when starting a process based on the file extension association.) SSIS packages then look in the current directory when the path to the configuration file is relative.
We use relative paths to configuration files all the time to simplify deployment, and have to always remember to open the solutions by double-clicking the SLN file.
I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).
I have been tasked to look into ways to automate the deployment process for our SSRS 2012 reports. Are there any good tools out there? I'm thinking of something along the lines of press a button and the report gets deployed.
Thanks!
To deploy our SSRS reports, we're using this lovely powershell project:
https://github.com/timabell/ssrs-powershell-deploy
Usage:
.\Deploy-SSRSProject.ps1 -path YourReportsProject.rptproj -configuration Release -verbose
or you can use the alternate parameter set:
.\Deploy-SSRSProject\Deploy-SSRSProject.ps1 -path .\AFS.Reports.rptproj -ServerUrl http://localhost/Reportserver -Folder MyReports -DataSourceFolder "MyReports/Data Sources" -DataSetFolder "MyReports/Datasets" -verbose
The full deployment story (for us):
ssrs-powershell-deploy scripts, .rptproj, .rds, .rdl files are all packaged into a nuget package by our build server.
Octopus Deploy extracts the nuget package on our SSRS server and calls Deploy-SSRSProject.ps1
Visual Studio Deployment
Visual Studio is actually really good at automatic deployment. I've used it a number of times with great results. You need to split your solution into separate projects for each folder on the report server and then it will take a bit of time to configure each project & deployment environment. But after that initial time investment it works wonders and when you add a new project you can simply copy the deployment settings for an existing project.
MSDN article: Set Deployment Properties (Reporting Services)
Rs.exe Utility
Alternatively you can use the Rs.exe utility which comes with SSRS. It is a command-line utility used for automatic deployment and administration. I haven't personally use this one, but I know of it. It is my understanding that there are also third party utilities which leverage Rs.exe in order to automate report deployment but I haven't used any of them so I can't recommend any.
More info on MSDN: RS.exe Utility (SSRS)
I'm sure there are also other third-party tools you could get but I haven't ever looked into them. I've always found the Visual Studio deployment functionality sufficient for my needs.
I have done it using devenv which is located in:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. The ... 10.0 folder is based on the version no. of your Visual Studio so I have only used this version so cannot vouch for anything else. If you view the help /? commandline switch you can see there are options to build and/or deploy a solution.
In brief I used: devenv {solutionfile} /Deploy {configuration} /Project {projectname}.
I did not use any deployment software but I did know how to code in C#.NET so pays to be familiar with System.IO and System.Xml name spaces.
Given the requirement deploy any file (so reports, datasets or datasources) that has been modified within the past 2 week sprint.
So basically my .net code worked as follows (NB: there are ares that you might have to consider first how well do you know how solution and project files work and if you have more than 1 platform - a platform for the uninitiated is a different set of project build and deployment settings):
Read the sln file line by line to get list of projects for the specific platform that are ready to be built/deployed, for simplicity my code assumed only one platform and all projects were to be deployed
The list from 1 gives me the subproject\subproject.rptproj settings in which I can break on the backslash to get the subfolder name from which I can iterate over all files in the project folder and check each file for the LastWritten datetime stamp of the file to determine what files that need to be deployed.
I back-up the entire file (declaration and contents)
If a file has not changed I edit the project file on the fly using xml and remove all unwanted files (ProjectItem's) not to be deployed
If there are dataset or datasource files changed then I also edit the respective configuration section of the project file and modify the particular configuration section accordingly
Run my build solution process i.e. devenv with commandline args (FYI: I did not encounter any .NET exceptions in this step)
Restore my project file
Providing your SSRS solution is configured correctly and the person running the .net commandline solution has permissions to deploy all should be well. Was easy enough to share my commandline solution source code to anyone else in my team to run to avoid having to white-list the exe if your company has employed such restrictions.
we have multiple ssis packages that need to be deployed on server .. is there a way to install all these together, perhaps?
Yes you can create a Deployment Manifest which will let you install all the packages in a project. To create this, you need to select the project Properties (on the Project menu), then select Deployment Utility and set CreateDeploymentUtility to True. By default, the path for this will be bin\Deployment under your project path. You can then copy everything in that folder to your destination and double-click the .SSISDeploymentManifest file to begin the install.
Alternatively, if you have sufficient rights, you can deploy a project directly from BIDS by entering the relevant destination server details in the project property pages (by right-clicking on the project name in Solution Explorer), then right-click and Deploy.