There are a number of post in relation to Visual Studio building projects when not necessary. However, none seem to cover this particular issue.
I'm running Visual Studio 2012 Professional Update 4.
In my solution, I have a unit test project that has a project reference to a BizTalk Transforms project. This in-turn has a project reference to a BizTalk schemas project.
Every time I choose to run a unit test, the whole solution is built, even though no changes have been made.
The first line displayed in the build window is as follows:
Input file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\FFF.Enterprise.WareHouse.Schemas.btproj.user'
is modified after output file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\bin\Release\FFF.Enterprise.WareHouse.Schemas.pdb'.
Note: it seems to be the .user file that's causing the rebuild.
Does anyone know how to prevent this? Strange but I only seem to be getting the problem with BizTalk proj files. I am seeing this behavior across multiple solutions but the problem file is always identified as a btproj.user.
This screencast illustrates the problem: screencast link
You should remove the *.user file from your source control.
These files store user specific settings and should never be checked into source control.
I had the same problem. BizTalk projects insist on updating the btproj.user file on every build, resulting in a full rebuild every time.
I solved the problem with the following workaround: Set the ACL Write Flag on Deny. The build cannot update the file and the projects are only build when actually needed.
In my case build time went from 10 minutes to 2.
If you have just opened the solution, even if nothing has changed since the last time you built, if you click Run All, it will as per the description in Test Explorer do a build.
I currently have a solution with a number of projects which include Unit Tests.
We've got a CI build and a separate Scheduled build and I would like to be able to run Code Coverage on the latter (not the CI).
At the moment we are using Visual Studio 2010 and TFS 2008. None of these can be changed.
I've looked around for hours and lots of suggestions mention a Process tab to select in the Build Definition however further investigation shows that the combination of VS/TFS that we have does not have this option.
Another source says to modify some testsettings such that they contain the Code Coverage option (which I have done) and then define the Test Settings file in the build - but I have no idea how to do this (http://www.codewrecks.com/blog/index.php/2010/06/14/running-code-coverage-in-tfs2010-builds/).
I have a testsettings configuration that will run code coverage locally so my issue is that I need the MSBuild TFSBuild.proj file to know which testsettings file to use when running it's tests (through the <RunTest>true</RunTest> option).
Any help on this would be greatly appreciated. I've trawled through the various other proposed solutions but none seem to match this. They either use a better version of TFS, or do something else.
EDIT. I suspect I might be restricted to using an Exec task within the build script and running the Vsperfmon.exe command with some arguments. If this is the case please provide an example because I've no idea how to capture the results from this command and tie them to my Scheduled build.
Thanks all.
I have a Website Project in Visual Studio 2010 along with a Class Library Project. When I try to build the Solution from Visual Studio 2010 it builds successfully but fails in TFS 2010 Build. I have some custom .dll files added to website and it throws error in my class that following method is undefined. The same thing builds 100% ok in VS 2010. Earlier I had a different project structure but since then I even changed the project and file structure following this article on MSDN for TFS 2010 Version control.
The Build fails and it drops a log file in the drop folder.
EDIT
Some of the errors in the log files are related like this.
error BC30451: 'AutoCompleteExtender' is not declared. It may be inaccessible due to its protection level.
error BC30002: Type 'IFileNameGenerator' is not defined.
These errors don't show up in VS2010.
This problem could occur when you are referencing a DLL from your solution that is not installed on the server or is somewhere in your project structure but not included in your TFS source control.
If you look at your build summary in TFS you have a 'View Log' option that shows more details. You can also specify a log verbosity in your buil;d definition template. Increasing this could give you some hints.
Read the log file. Searching for :error usually helps
Had the same problem with a contract in a nuget package. Turns out it was a bad merge. Compare the csproj/vbproj files and see if there are any differences in package versions
I realise that there are many older questions addressing the general question of NUnit v MSTest for versions of Visual Studio up to 2008 (such as this one).
Microsoft have a history of getting things right in their 3rd version. For MSTest, that is VS2010.
Have they done so with MSTest? Would you use it in a new project in preference to NUnit?
My specific concerns:
speed
running tests within CruiseControl.NET (either commandline or MSBuild task)
code coverage reports from CC.NET
can you run MSTest tests in debug mode
(We use ReSharper, so test-runners are not an issue for us. We have used NUnit for the last few years. We do not have TFS.)
List item speed is same, but MsTest may be a bit slower because it creates folder for test run every time
MSBuid and CC.Net is big pain. You can't run MSTest on computer without VS on it (not 100 sure about 2010, but with 2008 it is so)
not sure, sorry
yes you can, from visual studio
My recommendation is following: if NUnit satisfies you - use it, forget about MSTest
To correct some old information on the thread;
It IS possible to run 64 bit tests in 2010
From VS2008 forward it is not neccesary to have MSTEST create directories anc opy the binaries in, just disable deployment, in 2010 thats the default but you have to set it in 2008
2010 MSTEST is faster but as its a generalised test framework that also runs load/web/UI tests there are compromises in the design that will lead to it being slower. Jamie Cansdale appears to have managed to get perf increases with the lastest releases of TestDriven.net's support for MSTEST
I've mainly used NUnit, some xUnit and some MSTest. They seem functionality equivalent, but I don't like the MSTest test runner. It runs in visual studio so it either crowds the screen or is on another monitor getting in the way everytime I tab to visual studio. (I run NUnit on another monitor, but it doesn't cover everything on that monitor everytime I focus visual studio). It takes too many clicks to find out what test failed and why.
NUnit can run in the background until a test fails, at which point it shows you information about the breaking test. This seems like the ideal for keeping red/green/refactor going smoothly.
Nope. Same issues regarding appdomains and assembly resolving still exist. I would avoid unless you want the new goodness for other functional testing or integration with Team System.
I don't know much about CruseControl.net, but you can debug tests. We currently don't use TFS either, and the MSTest is working for us.
If you think you'll ever run your tests in 64 bit mode, use NUnit. MsTest is only x86.
One major difference between the two is that MSTest makes a copy of the current DLLs every time it runs a test. If you're doing TDD and running your tests frequently, this can eat up a lot of hard drive space.
If you're using MSTest, you can change this setting in Tools > Options > Test Tools > Test Execution. "Limit number of old Test Results to" is set to 25 by default in Visual Studio 2010. I usually change it to 1.
MSUnit runs your test cases under conditions that are different from the actual execution environment. Specifically, the deployed files differ from those that are deployed when you run your actual project. Nethertheless, there is the [DeploymentItem]-Attribute to specify which files shall be deployed by MSUnit. So if your application depends on any external
files, such as
database files
database configuration file
application configuration file
...
then MSUnit is not the right choice, because the MSUnit tests never cover what your file system is going to look like in execution environment. The Visual Studio Project File settings for deploying files (Copy always, Content, etc.) are ignored by the MSUnit runner. So those settings cannot be tested.
BACKGROUND: I have a sqlite file that is marked as COPY in it's properties. When I debug my WinForms application in VS2008 (or run it) it does the right thing and copy it to the debug/run area.
QUESTION: When I run unit tests (using VS2008 unit tests) it is not performing this copy. Anyone know how to get this working? So that my sqlite database file will be copied across before VS2008 tries to run the unit tests
You must either docorate your test with the DeploymentItemAttribute or configure deployment using the .testrunconfig file.
See this answer for more details.