Develop Reference

Roslyn Analyzer Rule does not fail the build

Following on from this tutorial from MS, I have created an analyzer for Roslyn.
According to the page, you can mark the rule as DiagnosticSeverity.Error, and this will cause the build to break:
In the line declaring the Rule field, you can also update the severity of the diagnostics you’ll be producing to be errors rather than warnings. If the regex string doesn’t parse, the Match method will definitely throw an exception at run time, and you should block the build as you would for a C# compiler error. Change the rule’s severity to DiagnosticSeverity.Error:
internal static DiagnosticDescriptor Rule =
new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat,
Category, DiagnosticSeverity.Error, isEnabledByDefault: true, description: Description);
In my code, I have created the rule more or less as detailed here:
private static readonly DiagnosticDescriptor Rule =
new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat, Category,
DiagnosticSeverity.Error, true, helpLinkUri: HelpUrl);
This rule works fine. It throws up the red lines, it displays the message in the errors list. However, the build succeeds, and I am able to successfully run the application.
NB: I've created this rule to capture Thread.Sleep for this example.
Is there additional setup required to ensure a rule breaks the build?

This is a feature of Analyzers running from a VSIX file.
If the IDE-installed rules ran as part of the in-IDE build, it would result in IDE builds and command line builds having potentially very different outputs. For example, a user with code-cracker installed as a VSIX could end up filing a bug report that an open source project does not build due to an analyzer error (or perhaps a warning when the project uses /warnaserror). They would be forced to either uninstall the analyzer extension or modify the rule set used by the project to disable some rule that only exists on one developer's machine.
In contrast, rules that are installed via NuGet become part of the project and part of the build. They run the same way across developer machines, and they run the same way in-IDE, on the command line, and in automated build environments.
Source: IDE rules don't fail builds
In order to make the build fail for the rules, you need to add the analyzer as a nuget package to the project. This will ensure that failures will cause the build to fail as expected.

MSBuild called by Process.Start() behaving differently between VS2010 and VS2013?

I have both VS2010 and VS2013 installed and am trying to run a program that compiles a .net 4.0 solution by calling MSBuild (C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319).
For the record, the code that does this looks like:
var processStartInfo = new ProcessStartInfo
{
FileName = pathToMSBuild,
Arguments = "C:\path\to\mySolution.sln /nr:false",
CreateNoWindow = true,
UseShellExecute = false
};
var process = Process.Start(processStartInfo);
process.WaitForExit();
I've checked the .sln, which contains a .vcxproj and .csproj file, and these only contain references to ToolsVersion=4.0.
When I execute the program in VS2010 (or open cmd.exe and run the MSBuild command myself) it works fine and compiles the solution. However, when I run the same program using VS2013 I get the following error from MSBuild:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Micros
oft.CodeAnalysis.targets(214,5): error MSB4175: The task factory "CodeTaskFacto
ry" could not be loaded from the assembly "C:\WINDOWS\Microsoft.NET\Framework64
\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll". Could not load file or assembly '
file:///C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Build.Tasks.v
12.0.dll' or one of its dependencies. The system cannot find the file specified
. [C:\...\solution\myProject.vcxproj]
I found this answer on msdn that actually solved this for me - after commenting out the offending lines from this file, I can call MSBuild succesfully from VS2013. But I don't understand why this is relevant since I thought I was running a v4.0 MSBuild to compile a project with ToolsVersion=4.0.
Presumably this is due to some environment variable getting set when I run/debug my program with VS2013? I can't find any details on the internet. Please could someone explain what is going on here?

You could try adding the /v:diag switch to your arguments. This will cause msbuild to run with output verbosity set to diagnostic. This will show you the state of env vars and the app domain at the start of each call and might help you to identify differences.
Note - take this out when you're done as it will significantly slow down the build process.

Problem
The error is a Could not load file or assembly and The system cannot find the file specified .. .vcxproj:
Troubleshooting
Open ProcessMonitor and run the build process until it throws the error. Stop the trace when it fails and investigate ProcMon's (Filemon) log to see where the MSBuild is looking for the .vcxproj or .xyz files/assemblies it cant find. Solve that!!
Solution
Put the file where its expected to be found.

Unit Test Adapter threw exception with no stack trace in TeamCity 7.1.5

We have an ASP.NET MVC 4.5 project. For months it has been compiling and all unit tests passing locally on our development machines and on the TeamCity 7.1.5 machine. Monday we updated to newer versions of some of our dependencies (specifically, to get OData 5.0.0-rc1 for select-expand).
The project compiles fine on our development machines and the build machine. It runs fine on our development machines and on both QA environments it's deployed to. All the unit tests pass on our development machines. However, about half (~300) of the unit tests now fail when run from TeamCity using the MSTest build runner, all with the same, useless error:
Unit Test Adapter threw exception:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I've tried everything imaginable. At first I figured there was a legitimate problem. Since there's no way to retrieve the LoaderExceptions property from TeamCity (why doesn't MSTest just display more information!?!?), I logged in to the machine TeamCity is running on, opened up the console, changed into the work directory that our build is running from, and ran the tests manually so that I could retrieve the property. ALL OF THE TESTS PASSED! There goes that theory...
After an entire day of Googling and reading other answers on StackOverflow, I've tried about two dozen different combinations of the following steps:
Changing the build from "Rebuild" to "Clean," running it without tests so that it just cleans, changing it back, and running it again.
Changing the build from "Debug" to "Release," running it, and changing it back again.
Cleaning agent sources from TeamCity admin pages.
Manually deleting entire work directory off of the agents, skipping the recycle bin and going straight to the netherworlds.
Deleting all source control (TFS) caches off the build machine and agents.
Telling TeamCity to clean the work directory before getting latest from source control.
I've reached the end of my troubleshooting capabilities. The tests just won't run anymore on the build machine, for apparently no reason at all.
What can I do? What the heck is going on?

The short answer to this is, "It's a bug."
I reported the bug to JetBrains. It appears that, though there might be some underlying problem with my project, it's only a problem when run from Teamcity, and it's impossible to retrieve the actual error message, so there's no way to know what that problem is. The runner should be catching the exception and printing out the LoaderExceptions property, but it isn't. Instead, it's just calling ToString() on the exception. The runner will have to be updated to look for this specific exception and print the LoaderExceptions property. Once that happens, then we can see the underlying problem, which may result in changing something in the project, or it may result in filing another bug with JetBrains.

Workaround
I spent quite some time debugging our Continuous Integration build failure while experiencing this bug. Since Jetbrains doesn't address the issue, I thought I'd post my workaround here so others have something to work with.
My problem was that the build failed on the step which runs the unit tests. Coincidentally the build which failed added a unit test project. When the newly added unit tests were excluded, everything ran successfully. Because of the reasons stated above and Teamcity not handling the exception properly, debugging options are limited.
I never found a solution which doesn't get your hands dirty, but what you can do is the following. It's basically manually running MSTest versus the test assemblies on the build agent and does require remote desktop access to it. In my case, Teamcity ran the unit tests from the following directory:
C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Out.
Run the following command to initiate the MSTest runner on the assembly which contains failed tests:
C:\BuildAgent\temp\buildTmp\Out>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:"C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll"
The output should give you the problem which actually makes the tests fail. In my case it turned out that the new project had a reference to Ploeh.AutoFixture with a different version than the version used in the other unit test projects.
Unable to load the test container 'C:\BuildAgent\temp\buildTmp\Out[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll' or one of its dependencies. Error details: System.IO.FileLoadException: Could not load file or assembly 'Ploeh.AutoFixture, Version=3.18.10.0, Culture=neutral, PublicKeyToken=b24654c590009d4f' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
Specific problem solution
In case you're wondering how to fix a similar issue, you can do the following. Open the package manager console (View -> Other windows -> NuGet Package Manager) and execute the following command.
Install-Package Ploeh.AutoFixture -Version 3.18.10.0
This adds the NuGet package (to the project selected on the dropdown) with a specific version, just make sure that all the projects are aligned in this sense.

VS2012 automated deployment - OutputPath property is not set for project

Ok, I know this has been asked a bunch of times...
I have tried to change the configuration and the outputPath, but still I have this issue.
I am setting up automated build and deployment for our product.
We have a single solution file and multiple projects within it.
Using VS2012 and the default build definition, I have set the "Items to build" to a single project - the one we wish to have build and deployment for.
Lets call this project "Forms".
When I run the build definition, it builds and says success. However, it gives a warning:
$/XXX/TRUNK/XXX/Forms.Web/Forms.Web.csproj - 0 error(s), 1 warning(s),
View Log File
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(610): The OutputPath property is not set for project
'Forms.Web.csproj'. Please check to make sure that you have specified
a valid combination of Configuration and Platform for this project.
Configuration='Release' Platform='Any CPU'. You may be seeing this
message because you are trying to build a project without a solution
file, and have specified a non-default Configuration or Platform that
doesn't exist for this project.
I have checked the .csproj file and there is a property group with the OutputPath specified.
I've also tried various combinations of configuration/platform, but the issue remains.
Does anyone have any idea what could cause this? It's driving me nuts. Without this fixed, no deployment is done... It seems to only build and doesn't even generate the .DLL files.

Try to delete the "Platform" environment variable.
(Visual Studio use this environment variable, which is possibly wrong.)
Then restart VS, and re-build the solution...

How do I programmatically compile projects and solutions in release with c#?

My dilemma is that I need to compile a large amount of projects and solutions as per the configuration settings specified in the files. I've found a few different ways to do this, and I've landed on using the Microsoft.Build.BuildEngine.Engine class, which has recently become deprecated.
Here's some sample code that illustrates its use: (note that node.Path is the path to the project file)
var builder = new Engine { BinPath = #"C:\Windows\Microsoft.NET\Framework\v3.5" };
var logger = new FileLogger { Parameters = #"logfile=" + Path.Combine(logdir, Path.GetFileName(node.Path)) + ".txt" };
compiler.RegisterLogger(logger);
bool success = compiler.BuildProjectFile(node.Path);
compiler.UnregisterAllLoggers();
return success;
My problem - it compiles in debug :(
Looking through the members of the class hasn't helped much as there aren't that many properties exposed. The one hint was the PropertyGroup property which seems to allow the setting of some project build options.. however it isn't clear how to get the resulting call to BuildProjectFile to output in release.
I'd really appreciate any help with this!

Do you have to do this through code? You may find it easier to use something like NAnT, along with NAntContrib, the MSBuild task is fairly comprehensive and makes it quite easy to specify which target to build, for example:
<msbuild project="${ProjectBasePath}\${ProjectName}.sln">
<property name="Configuration" value="debug"/>
</msbuild>
You can also call MSBuild from the command line, for example:
msbuild.exe project.proj /t:rebuild /p:Configuration=Debug
The advantage nant would give you, over msbuild is that you can script your build process. I, personally, find it quite easy to get on with and you can get a lot of power and flexibility out of it.
You can also call Visual Studio directly:
devenv.exe /Rebuild release "ProjectName.sln" /Out "c:\vs_errors.txt"
This will also output build output to c:\vs_errors.txt

I don't understand why you need to constantly compile. Settings files as you mention should be in app.config or web.config (depending it's a webservice). Settings files should not change the compilation of the app code. If it is I suggest you change your Programming model to allow for changing settings without recompiling.