There's a bug/feature in Visual Studio 2010 where you can't create a unit test project with the 2.0 CLR.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=483891&wa=wsignin1.0
This causes all sorts of problems when the project being tested is targetting the 2.0 CLR (ASP.NET MVC 2 on top of .Net 3.5 SP1 in this case) - crashes on debug, tests failing unexpectedly, in one case the test project doesn't even build because of the dependency on System.Web 2.0.0.0 which isn't available in projects targetting 4.0.
It's not possible to change the test project to target the 3.5 framework.
Does anyone know of a workaround?
Workarounds I'm aware of, but want to avoid, include:-
1) Upgrading the whole solution to target .NET 4
I want to host on Azure and it isn't clear at this point if/when support for .NET 4.0 will be added. See .NET 4.0 on Windows Azure?
2) Rolling the whole project back to Visual Studio 2008
This is a last resort as there are a number of features in 2010 that I really want to use
3) Building the unit tests in 2008 and managing the references manually
This will work, but it'll be a tremendous pain.
Any ideas?
It looks like Visual Studio 2010 Service Pack 1 will resolve this once it is released (see the heading 'Better platform support | Unit Testing on .NET 3.5')
You can get the Beta version with a Go-Live licence now...
You haven't suggested changing to a different test framework. Personally, I use NUnit and have for years. It's far more sophisticated that the stuff in 2008. I haven't had time to see what's changed in 2010 but I can't see MS catching up that quickly.
Related
I have some legacy projects with test libraries.
The projects (and unit tests) target .NET 3.5.
We are using VS 2017 enterprise.
I was able to locate some nuGet packages that would allow the tests to build correctly, but Test Explorer does not see the tests at all. I presume this is because there is no Test Adapter.
The packages I am using are:
Microsoft.UnitTestFramework.Extensions v1.0.0.3
Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated v15.0.26228
Most of the packages I found would not install due to a lack of .Net 3.5 support. Which makes some sense in 2017, but still.
Does anyone know what Test Adapter I can use to make legacy .Net 3.5 unit tests visible to VS 2017 Test Explorer?
Things I can't do:
use a different version of VS
re-target the libraries to a different framework version (they are for SharePoint 2010)
Rewrite all the tests for a different test framework (unless there's a very straight forward translation of the attributes/asserts I could do with find and replace, as there's a lot of tests)
Appreciate any tips!
We have Team Foundation Server 2013 installed with Visual Studio Professional 2015 and I've been able to get continuous integration builds working using the TfvcTemplate.12.xaml build process template and the "/tv:14.0" MSBuild argument. However, I can't seem to find a way to tell TFS to use the 2015 Unit Test suite.
This post Build VS 2015 Solution w/ Unit Tests on TFS 2013 Team Build worked around the problem by installing VS 2013 on the build server, but that means that the build server would use the 2013 testing framework rather than the version used by the developer.
Another option is to use an older build process template that uses MSTest, which supports the "ToolPath" parameter, but MSTest appears to be deprecated (MSTest V2). BTW, I tried using the MSTest V2 NuGet packages, but that didn't have any effect on the framework used by TFS, which made sense once I thought about it.
I assume that there should be some way to tie in a third-party testing framework, but the examples I've found use the older build process template.
Has anyone else found a solution for this?
If you need your test agent or test controller to work with TFS 2013,
use Agents for Microsoft Visual Studio 2013 Update 5 and
configure the test controller.
Source Link: Install and configure test agents
This is the official recommended practices, we don't suggest you to use some third-party testing framework for handling your situation (not sure if there were).
Besides just as MrHinsh commented, we encourage you to move to new web-based build system which is more excellent. For the detail benefit of VNext builds, you could refer to this article Why You Should Switch to Build VNext
If I use VS 2015 Community and create a new Project for 4.5.2, MVC, I get the Services folder for DI. If I install the Core 1.0 with 2017, I don't. It looks like MVC, but it is missing things. I know it is a Release Candidate, and I know that 4.5.2 and VS 2015 are mature, but Core 1.0 is supposed to have Dependency Injection built in.
Do I need to install something else?
We've been using VS2008 and soon will be upgrading to VS2010. I have been using MSTestExtensions for it's database rollback feature for integration tests via MSTest. It seems the open source project has not been having much contribution in the last 2-3 years. Thus, I was curious if anyone has tried to use it with VS2010. Does it still work?
Seeing that you can download the source code to the MSTestExtensions project, it might be worth getting the source and building it in VS 2010. Since the MSTest functionality in VS 2010 has not changed that much since VS 2008 (from what I've read), I would say you have a good possibility of getting the code to build. The resulting binaries could be used for your VS 2010 development (hopefully! :)
I can now verify that the 2008 MSTestExtensions dll does indeed work with Visual Studio 2010.
The only thing is it didn't show up in the list of .net references so I had to manually browse to where it was installed. In my case that was to C:\Windows\assembly\GAC_MSIL\MSTestExtensions. Just add a reference to the version 2.0 dll (VS 2008 version) and it will work as expected.
We have a build box that uses CruiseControl.Net and has been building VB.Net and C# projects using msbuild. All I have installed on the box as far as .Net is concerned is .Net 2.0 SDK (I'm trying to keep the box as clean as possible). We are now trying to get a C++ app building on this box. The problem we are running into is that the header files (e.g. windows.h) are not installed with the SDK.
Do I have to install VS 2005 to get this to work?
Edit:
As a couple people have answered, I had actually downloaded the 3.5 Platform SDK, but the applications built on this box MUST run on boxes that do not have 3.5 installed. By installing the 3.5 SDK on my 2.0 build box, am I compromising my build box?
Edit:
I'm going to leave this as unanswered, but thought I would add that I went ahead and installed Visual Studio on the box and all is well. I hate having to do that, but didn't want to run the risk of having a 3.5 SDK on my 2.0 build box. I would still love to hear a better solution.
Visual Studio is not needed, but for C++ you need the Platform SDK as well:
http://www.microsoft.com/downloads/details.aspx?familyid=484269E2-3B89-47E3-8EB7-1F2BE6D7123A&displaylang=en
Edit: There is also one for Windows 2008/Vista, not sure which is the correct one:
http://www.microsoft.com/downloads/details.aspx?familyid=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
No, you have to install the windows platform SDK.
You'll need to download this:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
Edit: #Michael Stum
You need the Server 2008 / Vista / .NET 3.5 SDK version.
Depending on what you are using in C++ (MFC, ATL, etc) you are probably going to have to install Visual Studio Professional (not express) as a lot of the libraries and headers are part of Visual Studio and not included in the SDK or Visual Studio Express (if you are doing managed C++ using .Net as the main framework then installing the SDK will be enough). We run our build boxes on VM's and so like to have as little installed as possible, so I spent a fair bit of time trying to get things working by installing as little as possible and for our C++ I ended up having to install Visual Studio.
I don't see why having .NET 3.5 would comprimise the build box - 2.0 and 3.5 co-exist without a problem. The only concern I could see would be a developer upgrading a solution to VS2008 without your "permission" and the build not failing...
In general, you need some set of SDKs (Software Development Kits) to be able to build, and some set of redistributable packages to run.
In case it's not obvious, you should be testing your product on an otherwise clean machine before you ship, so you know you got the dependencies right.