Why when I change build to debug x86 rather than "Any CPU", do all the calls to System.Diagnostics.Debug.Print() get skipped? I'm using a 64bit machine. Exception output still shows.
You probably changed to a 'Release' build too, and hence DEBUG is not defined.
No, they are only skipped when you compile in Release mode.
Related
I have an ASP.NET core 1.0 project I created in Visual Studio 2015 (update 3). If I try to build the project within VS I get the following in my output window and there are no errors in the Error List:
1>------ Build started: Project: QuickStartIdentiyServer4, Configuration: Debug Any CPU ------
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
However, if I build the project using the dotnet CLI command (dotnet build) it builds and runs just fine.
UPDATE:
Apparently, .net core does not work properly when running Visual Studio as Admin. You would think everything should work as Admin, I guess not... go figure.
There are simply too many reasons why this type of thing might happen. The easiest way to diagnose the problem is to change the build output verbosity under options to verbose. This might help put you on the trail:
With regards to this type of thing happening with .Net Core and ASP Core. I have noticed that the project.json dependencies json fragment is a bit buggy especially if you start renaming projects and changing their file system location.
If you see in the diagnostic below you know there is some dangling reference issue:
Done building target "_GetDependencyFragmentFiles" in project "<<?YOUR_CORE_PROJECT?>>.xproj" -- FAILED
May be you are not seeing build errors. Go to Error List window and change 'Show Issues generated' box from 'Build + Intellisense' to 'Build Only' and try to build again.
See if this helps.
I work with Visual Studio 2012, and I just switched my deployment tools from NSIS to InstallShield. I've added new projects to my solution for InstallShield installers. When I build in Visual Studio (the IDE) I've no errors, no warnings and I'm happy.
Now, I want to have a script that build the full solution without launching the IDE. But when I run MSBuild in the command line, like that
MSBuild MySolution.sln /t:Build /p:Configuration=Release
I get following error MSB4062
C:\Program Files (x86)\MSBuild\InstallShield\2012SpringLimited\InstallShield.targets(21,3): error MSB4062: The "Microsoft.Build.Tasks.AssignProjectConfiguration" task could not be loaded from the assembly Microsoft.Build.Tasks.v3.5. Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
My searches lead me to the conclusion that I must buy the Premier Edition of InstallShield to take profit of ISCmdBuild. But I can't afford it, and I think there might be another solution.
Any idea?
Using Fusion logging the MSBuild checks for the DLL here: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Microsoft.Build.Tasks.v3.5.DLL.
I copied
c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.v3.5.dll
to
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v3.5.dll
And the error is gone.
Alternatively open your *.isproj file and change from "3.5" to "4.0" on top on the tag:
<Project ToolsVersion="3.5"...> --> <Project ToolsVersion="4.0" ...>
Another solution is to force MSBuild to use the x86 platform. See https://stackoverflow.com/a/1074699/870604
If you're building from a TFS build, this can be configured from the build options:
I found the solution. Use the command devenv.exe instead of MSBuild.exe. It will be similar to launching Visual Studio and clicking the Build button. That's all!
devenv.exe MySolution.sln /build Release
I have to enabled diagnostic mode of MSBuild project build output verbosity to see this:
1>Done executing task "EnableExtension" -- FAILED. (TaskId:81)
1>Done building target "DeployVsixExtensionFiles" in project "myextension.csproj" -- FAILED.: (TargetId:93)
...
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.27
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
My problem is I cannot debug the Visual Studio extension package I'm working on, as the build output says something has failed. What's wired, the obj and bin folders with all content inside (including vsix package), has been created. I don't really know what special I've changed, because few hours ago everything was fine.
How can I investigate what has gone wrong ?
Btw: I'm using VS 2012 Premium Update 1
EDIT:
I remembered what I've done. While being in debug mode, I entered Tools -> Extensions and Updates, and uninstalled my currently debugged extension (without restarting VS after that operation). Further attempt of debugging (F5 after CLOSING Experimental Instance of VS) results in this mysterious build behavior.
My current workaround I've come up with after some time is to change the display name of the extension package in the source.extension.vsixmanifest file:
<Metadata>
...
<DisplayName>Change this name to sth else and press F5</DisplayName>
...
</Metadata>
Nothing else needs to be changed (unfortunately reversion to old name still fires this error, but at least developing and debugging can be continued).
UPDATE:
I've checked the windows registry for such problematic name, and found following PendingDeletions key:
HKEY_USERS\S-1-5-21-1832937852-2116575123-337272265-599953\Software\Microsoft\VisualStudio\11.0Exp\ExtensionManager\PendingDeletions
Under this key there is value pointing at my extension I've previously uninstalled (while being in the debug mode):
C:\USERS\G_159\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\11.0EXP\EXTENSIONS\JAROSLAW WALISZKO\MYEXTENSION\1.0\
Removal of this entry fixes that case.
Davide Icardi commented:
Another solution is to manually open the Visual Studio experimental instance. Starting it caused all the pending extensions to be deleted automatically.
To start the experimental instance, run this command in a developer command prompt:
devenv.exe /RootSuffix Exp
Update: I'm dumb - after installing the VS 2013 SDK, there's a shortcut to start the experimental instance in the Visual Studio 2013 folder of the Start menu.
I am using Bamboo [from Altassian] and it uses the devenv.com builder to build solution files. Currently, I seem to be getting a "false" error in my builds - that I've tried to solve by myself but just can't - so I thought I would ask.
Each build succeeds normally - without errors stemming from code - but seems to instead give this error
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load.
I've no idea why this is causing problems in the devenv.com environment and I can't figure out either how to "ignore" this error by some build command?
Try this ( from MSFT support )
Can you check if the dll is in the global assembly cache (open a VS 2010 command prompt
(Start | All Programs | Microsoft Visual Studio 10.0 | Visual Studio Tools))
Type in
Gacutil –l > list.txt
Notepad list.txt
Do you see an entry like
Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
If so, from the same command prompt, run fuslogvw, go to settings, select log bind failures to disk, select ok
Run your command line
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com /Build "Release|Mixed Platforms" "D:\Builds\19\Test VizXView\VizXView v1.8 Test Release Build - Weekly\Sources\VizXView v1.8\VizXView 1.8.sln"
Click on the refresh button in fuslogvw. Do we get any bind errors?
I had a similar issue related to running unit tests on a build server that was using devenv.exe (not devenv.com). I had a premium VS installed on the build server but I'd written the unit tests with ultimate (which 'has' load testing, even tho I'd not used it). I used fusion viewer to work out that the missing dll was LoadTest.dll which I copied from my laptop to the buildserver, I also removed references in my solution that were in version control to: *.vsmdi and *.testsettings (they're deprecated) and I removed from the build def a reference to a .testsettings file.
My guess would be that even though I wasn't running a load unit test the build agent was trying to load the LoadTest libs just in case. Hope that helps
edit ---
ok, my own problem here was that I've got both vs2010 and vs2013 on my laptop. When I added the first test project to my VS2010 solution, the project added actually has a dependency on the 2013 version of the UnitTestFramework.dll. My build server only has vs2010 on it so I got the missing assembly error. Switching the reference to the 2010 version fixed this.
I'm using partcover to produce codecoverage for a bunch of mstest powered unit tests.
I use the command line:
PartCover.exe --target "c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" --target-args "/testcontainer:c:\CrusieControlProjects\AcademyPro\AcademyTests\bin\Release\AcademyTests.dll" --include [AcademyPro*]*
This runs, all tests pass, but I end up with the output:
Results file: C:\Program Files\Gubka Bob\PartCover .NET 2.3\TestResults\Administrator_PSLV22 2009-03-31 17_54_18.trx
Run Configuration: Default Run Configuration
Target PageFaultCount: 10565
Target PagefileUsage: 27631616
Target PeakPagefileUsage: 31297536
Target PeakWorkingSetSize: 31498240
Target QuotaNonPagedPoolUsage: 8180
Target QuotaPagedPoolUsage: 217124
Target QuotaPeakNonPagedPoolUsage: 13012
Target QuotaPeakPagedPoolUsage: 255524
Target WorkingSetSize: 30310400
request target shutdown
<PartCoverReport date="2009-03-31T18:00:36.7676250+01:00" />
When I run with the --output command the xml file ends up with just
<PartCoverReport date="2009-03-31T18:00:36.7676250+01:00" />
Why might this be happening?
To fix this I ended up downgrading.
I was using version 2.3 (which is a dev build) and switched to version 2.2.
Now the tests run fine and I get sensible coverage data.
Maybe that will help someone.
I was having a similar problem with NUnit on x64. The problem was that I was using nunit-console.exe (AnyCPU). Switching to nunit-console-x86.exe (explicitly 32-bit) solved the problem.
I don't have access to an environment with MSTest, but if the executable you're referencing is AnyCPU, you might look for an explicitly 32-bit version of it on your system. Worst case, you could create one using CorFlags.