I copied the TestWindow folder (C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow) to a machine that doesn't have visual studio installed and tried running the vstest.console.exe command on an x64 cpp test dll.
vstest.console.exe tests.dll /tests:testmethod1 /platform:x64 /logger:console
This is the error I see in the event log.
Application: vstest.discoveryengine.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
Stack:
at Microsoft.VisualStudio.TestPlatform.TestRunnerService.DataCollectors.DataCollectionPluginManager..ctor()
at Microsoft.VisualStudio.TestPlatform.TestRunnerService.WcfTestRunnerService..ctor(System.Threading.ManualResetEvent)
at Microsoft.VisualStudio.TestPlatform.TestRunnerService.TestRunnerServiceHost.CreateServiceHost(System.String, System.Threading.ManualResetEvent)
at Microsoft.VisualStudio.TestPlatform.TestRunnerService.ServiceMain.Main(System.String[])
The FileNotFoundException was due to some required assemblies missing. I discovered these using WinDbg and copied them over to the TestWindow folder.
- Microsoft.VisualStudio.Diagnostics.Measurement.dll
- Microsoft.VisualStudio.Diagnostics.ServiceModelSink.dll
- Microsoft.VisualStudio.QualityTools.Common.dll
- Microsoft.VisualStudio.QualityTools.ExecutionCommon.dll
- Microsoft.VisualStudio.QualityTools.Resource.dll
- Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
These assemblies can be found at C:\windows\assembly\GAC_MSIL on the machine that has visual studio installed.
I also noted that if I removed the /tests switch from the vstest.console command, these extra dlls were not required.
Also copied the following dlls to the TestWindow folder (to account for cases where the target machine doesn't have visual c++ runtime)
- C:\Windows\System32\msvcr120.dll
- C:\Windows\System32\msvcp120.dll
In addition to having the TestWindow folder and the aforementioned GAC assemblies (ensure you have GAC assembly versions that match your version of Visual Studio) and the VSC++ assemblies if required, I also needed to ensure the latest version of the .NET Framework was installed. I was working with VS 2012 vstest.console.exe and was able to run the help menu once I installed the .NET Framework 4.5.2 Windows Update.
I found a simple solution : just install Visual Studio Agents on the server .
(In this case no need to copy/past the TestWindow folder.)
Related
In Visual Studio 2017, I go to the Package Manager to do a dotnet restore.
Then I get an error message
error MSB4019: The imported project "C:\Program
Files\dotnet\sdk\2.1.201\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets"
was not found.
I navigate to
C:\Program Files\dotnet\sdk\2.1.201\Microsoft
and the VisualStudio path is missing and hence the error message. How do I fix this?
If you have a mixed solution that contains both .NET Framework and .NET Core (web) projects, dotnet restore won't be able to build .NET Framework projects and will cause an error in newer versions of the .NET Core SDK, as detailed in NuGet/Home#6665.
If you are experiencing this error from the command line, but not from Visual Studio itself, you might have more luck building the full solution using MSBuild.
I Have VS 2015 only installed on my TFS 2013 build server, and get the following error:
TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid ''.
Other sites say to install VS 2013, but why would I have to install VS 2013 on the build server to run unit tests when I have VS 2015 installed?
I have the following switches on my build:
/p:VisualStudioVersion=14.0 /tv:14.0
(This is not a duplicate question as I am using TFS 2013 and am trying to use the Agile Test Runner not MS Test)
Check the solution in this case:
Install VS 2015 or Microsoft Build Tools 2015.
Edit build to use a build process template called TfvcTemplate.12.xaml.
Set MSBuild arguments to /tv:14.0.
But this setting only works for build, not test. As there is no way to set the tool version or tool path for "Run VS Test Runner" activity, installing VS 2013 should be the only way to get rid of this error.
I had a similar problem - was getting the error
TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid 'D:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow'.
It ended up being that even though Visual Studio 2015 was installed on the build agent, the user that the Build Agent was running as didn't have read/execute permissions to that folder.
I have a fresh Windows 8.1 Pro x64 install with a fresh Visual Studio 2013 Pro.
When trying to compile a project with Platform Toolset to Windows7.1SDK I'm getting
Error 1 error MSB6006: "CL.exe" exited with code -1073741515. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets 57 5 MenuBrowser
I tried running the supplied "Windows SDK Configuration Tool" and besides getting an error about Visual Studio 2005 and 2008 not being installed I think it did its job.
I tried manually editing the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
where I manually put CurrentInstallFolder as C:\Program Files\Microsoft SDKs\Windows\v7.1\ and CurrentVersion as 7.1.7600.0.30514. If I look at the project properties and click the different paths / variables in there -> more -> Macros, I can see that $(WindowsSdkDir) is correct.
Any idea as to what I should try? Never ran into this problem on the old development computer with Windows 7 and VS 2012.
L.E. as a note, if I try a new project with the v120 tools, it works, but I need the Windows7.1SDK tools.
When trying to compile a project with Platform Toolset to Windows7.1SDK...
That's not a valid selection in a "fresh" install for VS2013. Not very clear what you've been doing, it certainly isn't "fresh" anymore. Do treat Regedit.exe as a loaded weapon, the registry key set that configures VS has been getting pretty doggone convoluted as of late.
The compiler crashes with -1073741515 == 0xC0000135 == STATUS_DLL_NOT_FOUND. That's a pretty serious mishap of course, it should never occur when you target SDK 7.1 since that still uses the same compiler, only the SDK directory is changed. The compiler itself, as well as the DLLs it uses, are not part of the SDK and only are provided if the machine doesn't have VS installed. You can use SysInternals' Process Monitor to diagnose this, you'll see the CL.EXE process searching for a DLL and not finding it.
The correct way to target 7.1 is to use the v120_xp toolset selection. That builds programs that can still run on XP, it automatically also selects the 7.1A SDK that was installed on your machine. Do try to undo the changes you've made.
Referencing Yodans solution from
How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?:
As pointed out by Hans Passant cl.exe looks for mspdb100.dll (among others) and does not find them.
The needed files are in the directory mentioned in 7. below:
My working setup:
VS2013 needs to use VS2010 libs
Using WinSDK 7.1 build tools (v100) in VS2013
clean install, uninstalling everything mentioned in the sdk release notes (can be downloaded at http://www.microsoft.com/en-us/download/details.aspx?id=8279 under category Details)
Microsoft Windows SDK for Windows 7 (7.1) (the Windows SDK core-component files)
Application Verifier
Debugging Tools for Windows
Windows Performance Toolkit
Microsoft Help Viewer 1.0
Microsoft Visual C++ 2010 Redistributable
Microsoft Visual C++ 2010 Standard Edition
Additionally removed all .NET and VC++ related MS Software (not tested if necessary)
choosing Windows7.1SDK as Platform Toolset in VS2013
error MSB6006: "CL.exe" exited with code -1073741515
cl.exe looks for one of msobj100.dll, mspdb100.dll, mspdbcore.dll and mspdbsrv.exe
Added to PATH: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Build works and binary is usable!
A mistake I did:
copied files in 6. above to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin, believing this directory is in PATH, but it was not!
So better do as sugested in 7. above or by Yodan in How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?
The following steps work for me in VS 2017.
1.Close VS 2017.
2.Restart machine.
3.Open solution in VS 2017.
4.Build the project.
This time I didn't get following error and it builds successfully.
error msb6006 "link.exe" exited with code -1073741819.
I have been working on a project using OpenCV and have made a face detection project.
I would like to know why does an executable created using Visual Studio 2008 not run on another pc and give the following error:
"This application has failed to start because the application configuration is incorrect"
Perhaps you need the Visual C++ Runtime package installed.
Available for download .... here
You need to install Microsoft Visual C++ 2008 Redistributable Package on the machines you are deploying your application first - http://www.microsoft.com/download/en/details.aspx?id=29
The Microsoft Visual C++ 2008 Redistributable Package (x86) installs
runtime components of Visual C++ Libraries required to run
applications developed with Visual C++ on a computer that does not
have Visual C++ 2008 installed.
Another thing to note is you will have to take the binary from Release build (not Debug.) The Debug build wouldn't run on the deployment machine even if the VC++ Runtime is installed.
We are currently taking VS2010 for a testdrive and so far we are a little stumped with how it just won't cooperate with our existing Team Foundation Server 2008.
We still have all our projects on .NET 3.5 and whenever we are now building a solution that contains a unit test project (which automatically builds in .NET 4.0) the TFS won't build it.
The .NET 4.0 framework is installed on the TFS 2008.
The error we're receiving is:
[Any CPU/Release] c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(0,0): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
As a temporary workaround we are now forced to remove all our test projects in order for our solutions to build.
You need to install VS2010 on your build machine.
I'v just been trying to build V4.0 solutions on TFS2008, and altered the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config file:
<add key="MSBuildPath" value="" />
to
<add key="MSBuildPath" value="c:\Windows\Microsoft.NET\Framework\v4.0.30319\" />
The build of v3.5 and v4.0 solutions did succeed. But the unittest of the v3.5 solutions did not work.
Read about installing VS2010 on the build server, but read somewhere else: ( http://www.richard-banks.org/2009/11/how-to-build-vs2010-solutions-using.html ) that it is possible without installing VS2010.
: Text from that website:
This worked for us allowing a TFS 2008 build agent compile VS 2010 solution/project files without installing VS 2010:
Install .NET Framework 4.0 and .NET Framework 3.51 SP1 (for some reason, SP1 wasn't included with 4.0?)
Install Windows SDK 7.0A. When I'm writing this the SDK is still not released so we had to:
From a computer with VS 2010 installed, copy the SDK folder from %programfiles%\Microsoft SDKs\Windows\v7.0A and registry settings from HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\7.0A to the build machine.
Copy %programfiles%\MSBuild\Microsoft\VisualStudio\v10.0 to the build machine
Change ToolsVersion from 3.5 to 4.0 in your TFSbuild.proj file.
I think that was all. There was no need to change the build agent's configuration file.
Hopefully this will work.
Install "Agents for Visual Studio 2012"
http://www.microsoft.com/en-us/download/details.aspx?id=38186