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.
Related
We want to deploy a couple of static content files in the service fabric package (configs, metadata). As long as those files are in the root of the package, everything works fine. If we however put them in a subfolder, the files are not included in the package. Is this some kind of bug, is this by design or do we need to configure something?
Update
It seems that the problem is in our own custom deployment code (we package and deploy to service fabric ourselves). This is indeed working, as long as the files are marked with Copy to Output Directory.
Make sure that you've updated the project metadata for any such content files so that the "Copy to Output Directory" property is set to "Copy Always" or "Copy if newer". If the file doesn't show up in the service project's bin folder after executing a normal build, then it for sure won't end up in the generated package.
We've recently added the excellent script# to our project. Currently we have it so that our VS build simply copies the compiled .js file from the output directory to the scripts directory of our web app.
We've decided to make it a permanent feature and so would like to make it so that the .js file gets generated as part of our web build NAnt script to ensure that it's always up to date. Is there any way to do this nicely or do I need to call MSBuild from my NAnt script specifying the .csproj file to run the compilation?
Thanks
Stu
This isn't likely the full answer (given I don't have experience with NAnt), but I'll offer it anyway, as it may help.
A script# csproj is very much like any other csproj relying on msbuild. If you've got some way to integrate other msbuild projects into your NAnt build script, the same model should ideally apply to script# projects as well.
In the version of script# that is in the github repository, a web project can add a reference to a script# project (thereby becoming dependent on the script# project), and include an msbuild deploy task, that will copy over scripts from the built script# project into the web project. You can see this in action in the Todo sample (https://github.com/nikhilk/scriptsharp/tree/cc/samples/Todo)
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.
I am using the built in TeamCity NUnit runner to run tests stored in .DLL files.
My .DLLs are referencing other DLLs which are present in the same folder.
When running these, i am getting a FileNotFoundException for the referenced DLLs.
How can i fix this? I am thinking perhaps the TC NUnit runner is using some other dir as the main app execution folder, and thus preventing from files that are actually residing next to the test DLL to not load properly, but cannot prove this claim yet...
Anyone else encountered this behaviour?
OK the problem is solved and it is indeed silly and embarrassing:
I have set the NUnit test runner to execute these tests:
**/*.Tests.dll
This means that it will include tests from /bin/Debug/ and also from other folders, such as obj/
In these folders, no references are included of course, making the same tests run twice and some of these fail of course!
Paths are related to build checkout directory, not to any working directory. If you need another paths, use %reference% syntax to refer to TeamCity property with a directory path. Do you run it under Windows? Do you use TeamCity 6.5?
If that does not help, feed free to contact teamcity-feedback#jetbrains.com
In my case, the missing DLL was a native library and it could not be loaded because there was an incorrect version of VC runtime installed on the build agent. My solution was to add runtime DLLs (located in 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\x86\Microsoft.VC110.CRT') directly into the project (build action = Content, copy to output directory = Copy always). This also makes installation friendlier.
Hope this helps.
I think we can all agree, when a developer gets a project out of their source control system... it should successfully build.
Question:
What extraneous files do you omit and which are you certain to add?
Anything that's generated from the items you check into source control.
Things I check in:
Source files (usually .java for me, but can be other languages)
3rd party JARs
Configuration XML or .properties
HTML, CSS, JSPs for web apps
SQL scripts
Design (UML) and documentation (Word or HTML)
Unit test classes and any data I need to run them
Things I don't:
Compiled .class files
Generated JAR or WAR files
javadocs
JUnit report HTML and results
In addition to generated files, in Visual Studio I leave out mstest files (.vsdmi), resharper user files, Visual Studio user files (.suo).
Include information about the database schema (diagram), set up queries and other special config params
My global ignore pattern for TortoiseSVN is: *.vbw *.scc *.vbg */bin */obj *.bak *.user *.suo *.webinfo bin obj *.dll *.pdb *.exe which covers both VB6 and C#.
I always leave out compiled files, which for me are generally of the .pyc variety.