I am trying to debug my test case using resharper Unit test session
but i am not able to set break point at code
Error : The following break point can not be set
Line no.xx Character yy
The common language runtime was unable to set breakpoint
Version Details:
Resharper 8.01.14.856
Visual studio 2012 update 4
What I have tried
Upgraded resharper installation ( V. 8.2.1)
New installation of VS 2012
I have also searched similar question this,this and many other question but no where i am getting solution
Some facts
Same configuration on my team mates machine working fine, I also exported his VS setting and imported it on my machine still its not working
Resharper creates some folders under my project named testresult which contains my project dll's
Related
I have encountered a bizarre situation in which.....
a Win32 project (originally compiled/run using Visual Studio 2010) has been successfully carried over/updated and successfully compiled under Visual Studio 2015 on the same computer (mentioned just in case that is somehow relevant).
I now need to continue development of the project on a different computer. So I copy the ENTIRE contents of the project folder to an identically named folder on the new computer, with VS 2015 installed. The only difference being that the project folder is now on the D: drive rather than C: as in the original computer.
When I try to compile the program I get:-
fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
I experienced this error in the past with Visual Studio 2010 and fixed the problem as advised in previous articles such as:
Failure during conversion to COFF: file invalid or corrupt
In this case however the puzzle is that, as mentioned above, the project has already successfully compiled on the computer it was copied from AND the new computer appears to have a correct and up to date VS2015 installation (e.g. the issue cannot be due to incorrect version of the CVTRES.EXE file - as was case when the same error was encountered in the past with Visual Studio 2010)
As far as I can tell the configuration settings for both VS2015 installations, on both computers are the same. The only difference as far as I can tell being that on the new computer the project now resides in a different drive/path - although the project folder is indentically named.
Can this really be the source of the problem?
The problem has now been, apparently, solved. I tried the /verbose option but that did not reveal any information or insight of any use.
The computer on which the project had been transferred to had Visual Studio 2010 WITHOUT service pack 1 installed. As an entirely separate exercise I proceeded to install service pack 1 (from a previously saved/archived ISO file). It failed to install. I then uninstalled VS 2010 from the computer.
I then tried again to compile my project using VS2015 - and again it failed, giving the error 1123.
I then performed a FULL re-installation of VS2010. I followed this with an another attempt to install the service pack 1 - which then succeeded.
After all this I then attempted to compile my project in VS2015 - and it succeeded! The connection with the VS2010 may be completely coincidental? But I mention this here for the record in case anyone else encounters a similar circumstance.
The puzzle is how, if at all, can the state of the VS2010 installation influence the ability to compile the project in VS2015. The concern, more importantly, is that my continued ability to work on/compile the project using VS2015 will be dependent on the computer keeping VS2010 w/SP1 installed?!
I have MFC Dialogue based applications written in VC++6.0. Due to my work environment requirements I need to upgrade to Visual Studio 2010. I don't need to add any new feature, just compile with the upgraded visual studio.
Can any guide me on this?
What are all the primary requirements and how to start it?
Just open the project/solution in VS-2010. Convert it and compile.
You might get some compiler warnings/errors depending on your code, because the new compiler is more precise.
But most conversions lead just to a view warnings, like security stuff and others and should work directly.
From the VC++ team blog and Visual Studio 2010 C++ Project Upgrade Guide:
With Visual Studio 2010, C++ build system moved from the VCBuild based system to the MSBuild based build system.
The C++ project system is also built on top of the MSBuild build system.
There are some limitations, known issues or by design changes that you may run into during the upgrade process.
VS2010 supports upgrading from VC6, VS2002, VS2003, VS2005 and VS2008.
As in previous versions of Visual Studio, upgrade can be done either through IDE conversion wizards or from the command line (Devenv.exe /upgrade).
Here are the recommendations for upgrading your applications:
1) Set up the upgrade environment the same as your build environment
The upgrade process will try to load files and evaluate values during upgrade. If your projects use values that are not defined by the project files themselves, for example, values defined by environment variables, it is required that these environment variables are set up before doing the upgrade. Without these environment variables properly set up, you may get conversion warnings or errors caused by unevaluated values.
2) Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the corresponding platform installed under
'%vctargetspath%\platforms\Itanium'. Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
3) Use native Multi-Targeting to build against VS2008 toolset first if possible
In VS 2010, Native multi-targeting have been added which allows you to build against the Visual Studio 2008 toolset from within the VS2010 IDE using the new MSBuild-based project system. I recommend you to take advantage of this feature by using VS2010 to build against VS2008 toolset first when upgrading. This can help isolate any project system/build system related issues from the tools issues that you may run into after upgrade. This will make the move to the VS2010 toolset much smoother.
Upon upgrade, the property sheet files (.vsprops) are converted to their new format (.props). Likewise, project files (.vcproj) are converted to their new format (.vcxproj). Note, the new project files are generated alongside the old project files. A new file type (.filter.vcxproj) is also generated during conversion. The filter files contain the information that is used to display folders in the solution explorer. This filter information was originally part of the project file. This change was necessary because MSBuild requests a rebuild whenever the project files changes. By storing filter information in a separate file, the filter can be changed without triggering a rebuild of the entire project.
Note: Upgrade process will not convert the .user file. As a result, your debugging and deployment settings will not be preserved after conversion.
In VS2010, a new command line upgrade tool, VCUpgrade.exe is introduced. This command line tool is suitable for upgrading applications with only one project as it cannot take in solution file as input and parse solution information into project files. VCUpgrade.exe is located at: $(VSInstallDir)\common7\Tools directory. This tool will also be shipped in the next release of WinSDK so that the users can do command line upgrade of the project files shipped in WinSDK without Visual Studio IDE.
I have found various iterations of this question across a number of websites, however so far I have not found anything that provides a full answer that worked.
I have just set up a number of Visual Studio Test Agents that all appear to be behaving and running most of the unit tests we are planning on initially running on them. However when I came to checking one of the unit tests it is failing on the line:
using (ShimsContext.Create()),
With the stack trace:
Result Message:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables.
Having read some other posts I installed Visual Studio 2013 on the test agent and confirmed it would run the test locally. I then set COR_PROFILER_PATH to the profiler that was being used on my machine which was installed at: “C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\12.0.0\Microsoft.IntelliTrace.Profiler.12.0.0.dll”.
It then failed in the same place with the trace:
Test method threw exception:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to get profiler module handle 'C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\12.0.0\Microsoft.IntelliTrace.Profiler.12.0.0.dll'. The specified module could not be found ---> System.ComponentModel.Win32Exception: The specified module could not be found
The suggestion is the profiler has been loaded under a separate process and can't be used. Has anyone had any success with this or similar set ups? At a fundamental level can Visual Studio Test Agents run tests with Fakes?
Thanks
I know this is a bit old, so the OP probably got his answer, but for anyone else, I opened a ticket with Microsoft on this issue, and the answer we came to after an hour and a half of looking at my setup for this problem:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables.
, was that I was using mstest.exe and I should have been using vstest.console.exe. In my case it was because I have Fakes test in my code now.
I'm using Visual Studio 2013 update 4.
I was having the same issue with a project I was working on. I found this issue noted:
https://connect.microsoft.com/VisualStudio/feedback/details/832744/unable-to-debug-shims-based-tests-unittestisolation-exception
There was an attached project, so I downloaded the project and ran the only unit test. Same error - the unit test was not successful. However, I right-clicked on System under the References, and clicked Add Fakes Assembly. Once it had generated the fakes for System and mscorlib, voila! The test turned green.
I was able to reproduce the issue in my project - I did not have fakes being generated for System. Once I generated them for System, my tests went from red to green!
Side note -- If you don't want to generate ALL of the fakes for System and mscorlib, you can modify the .fakes files like so.
mscorlib.fakes:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="mscorlib" Version="4.0.0.0"/>
<StubGeneration Disable="true" />
<ShimGeneration Disable="true" />
</Fakes>
System.fakes:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="System" Version="4.0.0.0"/>
<StubGeneration Disable="true" />
</Fakes>
I could not disable ShimGeneration for System.fakes - the test would fail.
I hope this fixes the problem for someone else - the error is extremely vague!
(I'm assuming your Test Agent is also a Build Agent.)
Is the build service version synced with the Visual Studio version which is installed?
I had the same issue in the following environment:
TFS 2013
Build Server w/ TFS 2013
Visual Studio 2015.3 installed in the build server
When I updated the TFS version on the build server to 2015.3, the issue stopped happening.
I know it may not make sense, but solved the problem as the TFS 2015 XAML Build is compatible with TFS 2013.4 app tier.
We just spent a few days debugging mysterious build failures on our automated build machine, only to find that the WRONG version of visual studio was being used to build with.
Instead of VS 2012 Update 3, the automated build was using Update 1 or 2 (Or no update at all).
So what can I use to check that the correct version of VS is being invoked?
I would like to add a test at the beginning of the build that aborts the build with an informative error (If the wrong version of VS is invoked).
Note: This is not an issue of merely detecting _MSC_VER in code, but I want to enforce using VS Update 3.
I tried looking in my build log (set to diagnostic) to find anything, and all I found was this, which was not very helpful:
VisualStudioDir = C:\Users...\Documents\Visual Studio 2012
VisualStudioEdition = Microsoft Visual Studio Ultimate 2012
VisualStudioVersion = 11.0
I have one OPC ( OLE for Process control ) server project which is developed into visual studio 2005. I want to run it in visual studio 2008. The coding for the OPC server project is done in VC++. I want to connect my OPC client to this OPC server. When I was opened the OPC server project which was build into visual studio 2005 into visual studio 2008 first time it was asking for conversion wizard. I gone through that wizard & successfully finished that wizard. But when I build ( by right clicking on the project & choosing build solution ) it is giving lots of error near about 64 errors. Most of the errors are like - fetal error C1083:Can not open type library file:'msxml4.dll':No such file or directory, fetal error LINK1181:can not open input file 'rpcndr.lib' , error C2051:case expression not constant. only these 3 types of errors in am getting. All these 3 errors are repeated in Error list & becoming bunch of 64 errors. Please provide me the solution for the above issue. Can you provide me any suusgestion or link or any way through whcih I can resolve the above issue?
In Visual Studio Project go to Project properties dialog to use Linker --> Input Options:
1. Remove rpcndr.lib
2. Make sure for all such configurations add rpcrt4.lib
Reason to do this is that the Windows SDK no longer ships with rpcndr.lib.
Opening in VS 2008 is the only way to upgrade.
But it looks like you need to clean up some of the references... this will be a manual step (likely just need to set a few paths). Start by fixing the first error, it is likely many of the subsequent errors are a consequence of that first error.
Normal practice is to have a copy of referenced libraries (including typelibs) somewhere in your source tree, so you are not dependent on absolute paths into the OS or other application's install folders. (Or the continuing existence of that library).