I'm using Visual Studio 2010 and both the assembly under test, and the assembly containing the tests target version 3.5 of the .NET framework (that corresponds to the v2 CLR).
The problem is that, when I created the test project, even though I choose version 3.5 to target, Visual Studio added a reference to the v4 Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly. I guess this is forcing the tests to run under the CLR 4.0.
I wish I could just ignore this issue, but there is some quirky COM interop behavior (probably the COM component's fault, over which I have no control whatsoever) when running under the v4 CLR.
I tried adding the test framework reference by hand, but I couldn't find it. Does it even ship with VS10?
Is there anything I can do, besides running these tests "manually" in a dedicated v2 console application?
This is a known issue that will be resolved in the upcoming Service Pack 1 for Visual Studio 2010 (see bullet on Unit Testing on .NET 3.5). The SP is still in Beta. As far as I know, a final release date hasn't been announced.
Related
I have a .Net standard 2.0 project in a Visual Studio solution that contains some Azure functions. In the same solution, I've created a .Net Core 2.0 Unit Test project. I've added a project reference from the .Net Core Unit Test project to the .Net standard 2.0 library.
Despite the project reference, Visual Studio is behaving like I'm referencing a dll instead of the project. For example, if I try to use F12/Go to reference, it brings me to a 'From metadata' file instead of the actual code file in the other project. Additionally, codelens features like 'Tested by' (and even just 'referenced by') and the Live Unit testing icons in the .Net Standard project aren't working, since they don't seem to be aware of the Unit Test project at all.
Is there some way to get this integration working between the two projects? My Visual Studio is up to date (15.5.3 enterprise), and I'm not using any tools like Resharper or anything like that.
I'm also facing the same issue but so far the project reference vs dll reference is not the case. I believe this is an existing issue with Azure function projects. There is a thread in Microsoft community regarding this issue. The last comment from Visual Studio is as follows:
I'm closing this report, because in the last 90 days there was no internal developer activity and very small number of new votes or comments. Sorry, we would like to look at this further, but we just don’t have the time right now. Our goal in closing older issues such as this one is to keep customers informed on which issues are currently being pursued by Visual Studio teams. If you still have trouble with our latest version, please report it as a new problem.
I'm confused. We upgraded our project recently to .NET 4.5.1. We installed .NET 4.5.1 on our servers.
I'm referencing assembly System.Threading.Tasks.Dataflow from the GAC at C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Threading.Tasks.Dataflow\v4.0_4.5.9.0__b03f5f7f11d50a3a\System.Threading.Tasks.Dataflow.dll
CopyLocal is set to false as (I assume) it's part of the Framework, so should be already installed wherever the app is deployed.
The trouble is, when running on the server, it says it can't find this assembly.
I've read here that is is part of .NET Framework 4.5:
but the library is now built-in with .NET 4.5.
...and I've read here that it isn't!
The TPL Dataflow Library (System.Threading.Tasks.Dataflow namespace) is not distributed with the .NET Framework 4.5
What gives? It doesn't look like it is. Is it just part of the 'targetting pack'? Is it me, or are these in-place upgrades more agro than they're worth?!
I'm not sure why that page says it is part of .NET 4.5 -- it's still an out-of-band NuGet release, like Entity Framework, MVC, etc.
I recognize this question is pretty old, but I wanted to add my solution as well. I found adding the below two items to the Visual Studio 2019 install (run Visual Studio Installer > Modify > .Net Desktop Development) the problem went away and it was able to pull System.Threading.Tasks.Dataflow from the GAC.
Edit: Installing Visual Studio 2015 also seemed to be required. Obviously it isn't VS 2015 itself, just something it comes with. But there are too many packages for me to figure out which one easily.
Edit2: This isn't really the best solution, more of a stopgap. MS suggests downloading it through Nuget. https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.dataflow?view=netcore-3.1
The TPL Dataflow Library (the System.Threading.Tasks.Dataflow namespace) is not distributed with .NET. To install the System.Threading.Tasks.Dataflow namespace in Visual Studio, open your project, choose Manage NuGet Packages from the Project menu...
Our product previously built in Visual Studio 2008 and used GoogleMock 1.5.0.
Now, after porting our product to Visual Studio 2010, any unit test DLL that uses GoogleMock will not load in visual Studio's Test View and consequently can't be executed.
Our production code is written in native C++ classes exported from C++ DLLs.
Our unit tests are written in C++/CLI so they can be hosted directly within Visual Studio. The C++/CLI unit tests exercise our native C++ classes, and GoogleMocks previously played quite happily in this scenario.
We build GoogleMock into static libs that use Multithreaded DLL at run time. All our production code also uses Multithreaded DLL.
We have tried GoogleMock 1.5 and 1.6 RC, both rebuilt within VS2010. But the problem arises with both versions of GoogleMock.
To reproduce, simply:
Create a new C++ Unit Test project
Add gmock.lib and gmock_main.lib as linker inputs
#include <gmock/gmock.h> at the top of the C++/CLI unit test header file.
The project will build fine, but the VS Test View cannot load the new unit test DLL. If you comment out the gmock.h inclusion, the DLL will load in Test View and its test fixtures will execute.
I am hoping that another VS2010 developer has encountered this problem and can suggest a fix.
My set-up:
Windows 7 x64
Visual Studio 2010, Service Pack 1
GoogleMock 1.5, or 1.6 RC
Our app is built as 32-bit (Win32 and x86).
All our C++ code, including GoogleMock, is compiled using VS2010's vc100 compiler. Our C++/CLI code is also built for .NET 4.0.
Thanks.
Having the same code setup as dripfeed (using Google Mock to test c++ native classes with MSTest), we got Google Mock 1.6 to work by building Google Mock with the /CLR compilation setting.
We now have successfully implemented some tests with Google Mock!
Note: Putting the /CLR setting may require to adjust other compilation settings.
I think I read somewhere on the documentation that it is a Microsoft's bug...
When I change the target framework of any project in Visual Studio 2010 it does not actually change the System assembly references. For example if I target v2.0 and check the properties of System and System.Data I can see that they are still both v4.0. If i change the target to v3.5, System stays at v4.0 but System.Core changes to v3.5.
Because of this I am truly not targeting anything except v4.0.
There may be something strange in your install. I just created a WPF project, keeping the default settings, thus targeting .NET 4. Then, I switched to 3.5. VS asked to reload the project and then the targeted runtime of the references was v2 (correct) and their version was 3.5 (with an error that Microsoft.CSharp and System.Xaml were missing, which is understandable).
Then, I did the same for .NET 3 and 2 and got the same results: after reloading the project, the version of the referenced DLLs had changed were it made sense (System.Data is always v2.0).
When using the CLR v2, the vshost debug helper had its name changed to something like vshost-clrv2.
I've reinstalled Visual Studio several times and it hasn't solved anything. After uninstalling there is 10.0 stuff laying all over the place leading me to believe the uninstaller is also leaving what ever is causing this issue. I'm going to have to reinstall the OS to get the issue to go away.
I also wanted to link to my earlier post because this post has more information about how I originally discovered this issue, contains a link to the Microsoft Connect bug report I opened and links to several other users experiencing the same problem: Visual Studio 2010 Can no longer build .NET v3.5
I’m working on the build process for a VS 2010 solution and some projects within it target the .NET framework 4.0. As far as I know, to have this type of solution built by TFS 2008 we will have to change the version of the MSBuild.exe file used by the build agent – modifying the TFSBuildService.exe.config file, pointing MSBuildPath entry accordingly.
Do you know if this will have any impact to existing project builds that target the 2.0 and 3.5 framework? Are you aware of any known issues with this type of set up?
We made such upgrade from VS2008 to VS2010 without the TFS migration (so it's still in 2008 version). Only problem we had was with build machine (cause we have only one) so we had to configure SideBySide builds. We had projects in VS2008 solution with MSBUILD scripts, some of them were migrated to VS2010.
Here's the solution http://www.codeproject.com/KB/architecture/SideBySideTfsBuild.aspx
After changing we didn't experience any problems, yet:)