In my SSIS project folder I have extra files in addition to the three package (.dtsx) files that I created. There is a ProjectName.database file, a ProjectName.dtproj file, and a ProjectName.dtproj.user file.
When I build the project, the dtsx files are copied to a folder called "bin" inside the project folder.
When I create a deployment manifest, the three package files are copied to a folder called "bin/Deployment" along with a new ProjectName.SSISDeploymentManifest file.
Which of these files should I check in to source control?
I think only the three package files and the deployment manifest are useful to me.
You will want to keep:
*.dtsx - your packages
*.dtproj file - project files
.sln file - solution file - if You have only one project you might not have this one
*.database - take a look at quotation below
deployment manifest file - allows you to deploy your packages to a target location using a wizard
MSDN states following:
The *.database file contains information that Business Intelligence Development Studio requires to open the Integration Services project.
*.dtproj.user and .sln.suo files are not needed because they (from the same link): contain information about your preferences for working with the project.
Related
I currently switched to eclipse and trying to migrate my projects. I created a java-workspace and used 'File->Open Projects from File System'.
The project with all the folders is added, not only the 'src' but everything I put into it (datasheets, documentation,...). Also the libraries are added two times. One time in the folder and what seems like a link to the compiled library.
folder structure
In netbeans I just added the desired library to the /libs folder and linked it to the project.
Can I manually add folders and/ or libraries to existing projects? Why are there two instances of the libraries?
By using Open Projects from File System, folders containing .java files has been configured as source folders (source code intended to be compiled). This can be undone via right-click Build Path > Remove from Build Path (the reverse function is Build Path > Use as Source Folder).
In the Package Explorer, source folders are shown as virtual folders. If the source folder is not a subfolder of the project, it is displayed as virtual folder in addition to the project subfolder to be able to navigate to that non-source project subfolder (in your case you have a single src source folder and in addition to the non-source folder lib you have multiple virtual lib/... source folders).
The node Referenced Libraries lists all JARs and class folders on the Java Build Path (classpath/modulepath). To remove something from the Build Path, right-click it and choose Build Path > Remove from Build Path. JARs can be added to the Build Path by right-clicking the JAR and choosing Build Path > Add to Build Path. Class folders can be added only via Project > Properties: Java Build Path in the tab Libraries with the button Add Class Folder....
I dont know if this is a workaround or good practice for migration:
Create a new Java-Project in Eclipse
add desired Folder structure (including /libs)
In 'Project->Properties -- Libraries' add libraries manually
Clean and Build Project
I have to test functionality and stability but it seems ok.
I have a PS1 script that I use in all my projects to sign the assemblies. Until now I copied this file over to all my projects. Now I wanted to create a nuget package with the PS1 file.
I created a nuspec file and put the file in "content". Unfortunately nothing happened. Then I tried to put it in lib. Still noting happened. When I restore the package in my project no files where created in this project.
When I analyst the nupkg file with my 7-Zip the file looks OK. The ps1 file was in content, lib respectively.
I didn't found anything to this topic online. Can someone explain to me, how to create such a NuGet-Package?
When a project using packages.config installs a NuGet package, the package's tools\install.ps1 script will run. However, this no longer happens when the project using the package uses PackageReference (such as SDK style projects, used by .NET Core).
Similarly, the files in the content folder of the nupkg are copied into the project on install, but only when the project uses packages.config. PackageReference projects use the contentFiles folder in the nupkg, however the behaviour is different. Those files are copied only on build, not install, for .NET Framework projects and on publish for .NET Core projects. Probably not what you want for signing assemblies.
The feature you probably want to use is including MSBuild props and targets in your package. Note that the props and targets file names must match the package id exactly for NuGet to use them. You probably want to use afterTargets="build" at a guess.
I have a Visual Studio 2015 solution with many projects. For one of the projects I would like the files from NuGet to download to a specific folder in my project. For example, I intend to use Bootstrap and also Signalr. I would like Bootstrap to download everything into one folder in my application, and not create folders within my project root. For example, I have a folder called 'Libs' in the project and would like those libraries to use 'Libs' as their root folder. This is due to an external build solution that handles everything in the 'Libs' folder.
I've found these docs about using a NuGet.config folder for the solution, but this does not handle my problem. Any ideas?
As far as I'm aware, this isn't possible. Each Nuget package is written with specific instructions on how to install into a project. One of those instructions is where to put files, another example would be what transform to apply to the web.config. Nuget doesn't specify a way to modify these instructions. The only thing you could do would be to modify the packages yourself - download the .nupkg file and open it up as a zip file, you will be able to edit the folder structure from there.
Problem
When attempting to build an SSIS package deployment utility by right-clicking on the solution and choosing "build", the build fails with an error message similar to the following:
Error 204 System.ApplicationException: Could not copy file
"MyPath\MyFile.dtsConfig" to the deployment utility output directory
"MyPath\bin\Deployment".
---> System.IO.IOException: The file 'MyPath\MyFile.dtsConfig' already exists.
This error can be caused by casing differences in the configuration file path. In some instances SSIS will treat c:\MyPath\MyFile.dtsConfig differently than c:\mypath\MyFile.dtsConfig.
I tested this with two different computers connected to the same TFS server. One pc had TFS mapped to C:\Packages. The other pc had TFS mapped to C:\packages. Creating a package and running on the first pc would create the deployment without any problems. Trying to create the deployment package on the second pc would result in the could not copy exception.
I manually edited the .dtsx file on the second pc. Changing the casing of the configuration file path under DTS:ConfigurationString= in the .dtsx file allowed the package to work correctly.
To get the package to work on both computers I updated the local path for TFS to have the same casing.
Cause
This is caused when SSIS is attempting to deploy multiple copies of the .dtsconfig file to the output directory. By default, SSIS will copy both all dependent files (including .dtsconfig files) and any files added to the solution under the Miscellaneous folder.
If you have added the file to your solution, but failed to repoint the Package Configuration to the new location, both copies will be deployed, and the build will fail.
This scenario can occur when you:
Create a package using a Package Configuration with a .dtsconfig file
Copy the package to a new directory without editing the Package Configuration
Add the configuration file to the project by right-clicking the solution, choosing Add --> New Item, and navigating to the file
Build the package.
Solution
To fix this, repoint your Package Configuration to the file underneath your solution directory. This can be done through the editor, or can be done by viewing the XML code of your package and manually editing the path of the file, such as with the following:
<DTS:Configurations>
<DTS:Configuration
DTS:ConfigurationString="MyPath\MySolution\MyFile.dtsConfig"
DTS:ConfigurationType="1"
DTS:CreationName=""
DTS:DTSID="{93222D3D-7AFF-1F2D-9UB8-B5E7X256BBE5}"
DTS:ObjectName="MyFile" />
</DTS:Configurations>
Further reading can be found here.
Is there a way to preserve folder structure with MSTEST deployment?
I have a situation with some existing code where I have .config files in a subfolder (called "Configuration"). I can specify this folder using MSTEST deployment but, in it's infinite wisdom, MSTEST just copies the files from this folder to the run folder (TestResult\\Out), i.e. it does not create a subfolder called Configuration. This royally screws up the code and it fails. I don't really want to have to start using complicated pre-test scripts to create folders etc.
Any ideas gratefully received.
Matt
I think I had the same problem...
My tests used a folder called xsd and I wanted to deploy the folder to the test \OUT directory. When I did this, the files inside the xsd folder were copied to the test \OUT directory, but I wanted the folder xsd into the test \OUT directory...
To solve this I read this. (Wayback machine has an archive of this page here)
If you're using the DeploymentItem attribute, it takes a second argument for the name of the directory to copy the files into. If you use the same name as your folder it preserves everything.
To use your test case you'd do:
[DeploymentItem("Configuration", "Configuration")]
class TestClass
....
and it would work.
Yes, you can. read the article Do MSTest deployment items only work when present in the project test settings file?
It explains how to map deployment items.
In Visual Studio 2012 the output directory is the working directory which means that the DeploymentItem attribute isn't needed for the general case (where you don't have specific per-test or per-class deployment items). You can simply click Project | Show All Files and include the subfolder and files in Visual Studio with the 'Copy Always' or 'Copy if newer' attribute to your project and the files will be copied to your output directory with hierarchy intact. The same applies when running vstest.console.exe from the command line.
See here for more information about Deployment Items in Visual Studio 2012.