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...
Related
I have a problem with the MWArray.dll which is the original dll library from mathworks compiled from Matlab. This dll works under visual studio but not under unity. The goal was to compile under matlab a simple function mycos which calculates a cosinus and uses it under unity with the second dll MWArray mathworks library.
I made a test under Visual Studio and it works well. I have no problem to read the dll and make a call to the mycos.dll class. I made a typical c# project with two references on MWArray and mycos.
But when I try under unity, by putting the two dll under a plugins folder and configure unity 2018 on .NET 4.0 because the dll are compiled with the .NET framework 4.0.
Unity can read the dll but when running I get an error:
NotImplementedException: The requested feature is not implemented.
System.Security.Principal.WindowsIdentity.GetCurrent (Boolean ifImpersonating)
(at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Security.Principal/WindowsIdentity.cs:166)
If I want to use matlab for a research project which was coded in matlab with advanced high level math functions which going to be difficult to recode under unity with c#. So the easy way is to use compiled package from matlab compiler. So is there someone who did this already?
The solution consists in NOT using MWArray.dll in Unity project because of incompatibility with Mono. Create a Visual Studio project (when creating new select the type "console applicatiion"), it MUST be separated from unity project directory, and use it as an application server; in fact in that app you can use MWArray.dll, remember that you have to configure your project configuration to x64!!! In the Unity project create a client app to communicate with the other server project.
I've browsed around StackOverflow but couldn't find any pratical solution to something that would seem to have such an easy solution: I had a bunch of .Net projects that were developed back in VS2005 or VS2008 and I imported them into VS2010. One of them is a C++ project, which currently targets framework 4.0 (not by my choice). One of our clients is having a problem running this application, the lack of a MSVCP100D.dll. I checked this thread what is MSVCP100D.dll? and the most accepted answer is simple: having the client install Microsoft Visual C++ 2010 Redistributable Package. However, the client is stubborn enough not to install it and I know for a fact that they have Microsoft Visual C++ 2008 Redistributable installed. So, if I'm correct in my conclusions and MSVCP100D.dll is new to VS2010, I could just target a previous framework version, rebuild the project in VS2010 and I'd be good to go. The problem is: how do I chance a VC++ target framework? I could find several guidelines to change C# and VB projects, but none about VC++. Any pointers?
Edit: To you guys who suggested that I compile it in Release mode: I am! It's been pointed out that the "D" stands for debug, which is rather strange.
Actually, you are using the debug version of the runtime (That's the "D"). Did you try compiling with a non-debug version?
Another possibility to consider would be to statically link with the runtime library. Your program will be larger, but will not have the DLL dependency.
Go into the project's properties.
On the lefthand side, go into Configuration Properties > General.
Look at the Platform Toolset value. Select v90 from the drop down list to target 2008.
See here for further details:
Visual C++ 2010 compatibility with VC 2008
See here for yet even more details:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
Also as Dark Falcon mentions, that's the debug version of the runtime.
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.
I'm having some troubles debugging a solution which contains both a native ANSI C DLL project and a managed C#/WPF application project.
I call the functions exported by the DLL using the LoadLibrary/GetProcAddress Win32 API functions (DllImport attribute is not applicable for my program as the DLL is selected by the user). Both projects are built using the Debug configuration. The native DLL is copied to the bin/Debug directory of the C# program. When I debug the C# project, I can't step into the native code.
Is there a way to step into the native code?
It works when I debug the DLL project using the C# program, but then I can't step into the managed code...
I'm using Visual Studio 2010 Professional and Visual Studio 2010 Ultimate.
lg,
Dominik
In your C# Project: Project + Properties, Debug tab, tick "Enabled unmanaged code debugging". Single stepping from managed code into unmanaged code isn't going to work. You need to set a breakpoint on the DLL function you want to debug.
Is it possible to switch off managed code (and switch on unmanaged code) for c++ coding, so that programs (exes) made are run direct to native machine code in Visual Studio 2008?
Also, is it true that after the first time a .net (managed) exe runs (say written in C#) the exe gets converted to a native code one (like the old c++ ones pre .net)? Or is there a way to make it compile direct to native code if it was written in C#?
The answer to both of these questions is yes.
You can create unmanaged c++ code projects in VS which do not need .Net. You can also link unmanaged C++ code to managed C++ code and (sort of) get the best of both worlds - although the matching of calling parameters between the to systems is interesting.
You can also use the ngen .Net utility to pre-compile .Net projects to pure code. However in doing so you loose some flexibility. The JIT compiler will take account of local capabilities when compiling a .Net project. So if you distribute a .Net project as generated by VS then ngen on the local machine that runs the program will do the compiliing. However if you use ngen on your machine the precompiled code will be tied to the processsor capabilities of your system.
As per Joel's comment. regardless of using ngen or not, you still need .Net framework on the target machine.
In thinking about it, the use of ngen to pre-compile a .Net project probably is no worse than compiling an unmanaged c++ project to native code.
To do what you want for C#, you would use ngen.exe, which comes with the C# compiler. You run that command on the image, and it gets added to the GAC as native code.
As far as i know, you can switch temporarily to unmanaged code, i.e. using unmanaged variables etc. by marshaling. Take a look here: http://msdn.microsoft.com/de-de/library/bb384865.aspx