On compilation errors in one of my projects, the build results page on TFS is significantly less informative than I'd hoped; I only get this:
I had hoped more for something like this (from a different project built the same way):
What do I need to do to get TFS to show the specific errors?
I build both projects using Cake build with the following target definition:
Task("Build")
.IsDependentOn("Update version")
.Does(() =>
{
Information("Verbosity: {0}", verbosity);
MSBuild(solutionPath, settings =>
{
settings.SetConfiguration(configuration);
settings.SetVerbosity(verbosity);
});
});
This sounds like it could be solved by using a custom MSBuild logger. Currently we do not have one built into Cake, but if you add an issue to Cake's issue tracker we can take this into consideration for a future release.
As a temporary solution, you could write a custom logger and provide it to the MSBuild alias using the ArgumentCustomization property on the MSBuild tool settings.
If TFS provides a MSBuild logger out of the box, you should be able to reference that one.
Related
I'm trying to develop an engine and I was looking for a GUI library in C# in order to build the editor for my engine. I found Avalonia but I'm having some problems setting up the whole environment.
I'm using Premake5 as build tool mixing C++ and C# but I think the problem here is not the languages mixing.
I'm getting this error when I generate my visual studio solution file. Sorry about the image, I needed to post it that way cause when I press the "Open Configuration Manager" the error is gone and exit the Configuration Manager window the compilation works as expected, quite weird.
Here's my code:
This is the premake5 script I run:
include "Dependencies.lua"
workspace "LeafEngine"
startproject "LeafEditor"
configurations { "Debug", "Release" }
platforms { "x64" }
flags { "MultiProcessorCompile" }
outputdir = "%{cfg.buildcfg}-%{cfg.system}-%{cfg.platform}"
group "Dependencies"
include "Leaf/vendor/glfw"
include "Leaf/vendor/imgui"
group ""
include "Leaf"
include "LeafEditor"
include "LeafGame"
Leaf is my C++ engine and LeafGame just a C++ test. Leaf editor is the C# project, which looks like this:
project "LeafEditor"
kind "WindowedApp"
language "C#"
clr "On"
targetdir ("%{wks.location}/bin/" .. outputdir .. "/%{prj.name}")
objdir ("%{wks.location}/bin-obj/" .. outputdir .. "/%{prj.name}")
dotnetframework "net6.0"
nuget { "Avalonia:0.10.13", "Avalonia.Desktop:0.10.13",
"Avalonia.Diagnostics:0.10.13", "Avalonia.ReactiveUI:0.10.13",
"XamlNameReferenceGenerator:1.3.4"
}
files
{
"src/**.cs",
"src/**.xaml",
"src/**.xaml.cs",
}
links
{
"Microsoft.CodeAnalysis.CSharp.NetAnalyzers",
"Microsoft.CodeAnalysis.NetAnalyzers",
"System.Text.Json.SourceGeneration",
"Microsoft.NETCore.APP",
}
filter "system:Windows"
defines "LF_WINDOWS"
filter "system:Unix"
defines "LF_LINUX"
filter "configurations:Debug"
defines "LF_DEBUG"
runtime "Debug"
symbols "on"
filter "configurations:Release"
defines "LF_RELEASE"
runtime "Release"
optimize "full"
Another curious thing about Avalonia: as you can see I only have one available platform ("x64") for building. Well, Avalonia compiles with ("Any CPU") platform and that also breaks my whole building set up. Besides, Avalonia gets compiled with Any CPU when I load the project not when I compile the project, is that right?
Thanks in advance, this error is killling me.
I just had the same issue, both when my C# project was built with premake and with it as an external project.
The solution (granted I gave up on premake for C# so this may only apply to externalproject) is to not add architecture or any specific platform to your workspace, and instead add it to all but your C# project. I would leave a comment since this might not be the answer you're looking for, but I don't have enough reputation. Anyway, for example,
workspace "Lotus"
startproject "LotusEditor"
configurations
{
"Debug",
"Release"
}
project "CppProject"
architecture "x86_64" -- sets CppProject as x64 but not the workspace
-- more project config
externalproject "CsProject" -- no architecture/platform set for this. Might work for non externalprojects too
location "path"
uuid "insert uuid"
kind "WindowedApp"
language "C#"
Even with my project made manually not with premake, and set with target platform as x64, it still seems to want "Any CPU" as the configuration, which premake can't do.
I want to apply for my own sonarqube custom rule using fxcop.
SonarScan succeeded with MSBuild, but sonarqube did not reflect the rule!
I referenced this url - https://github.com/DanielHWe/sonar-fxcop
I tried many times. please give some suggestion if you have experience about this problem.
My Development Environment
Visual Studio 2017
MSBuild 15
Sonarqube 6.7.7
SonarScanner for MSBuild 4.6.2
FxCop plugin 1.4.1
C# plugin(sonar) 7.15
First, I've set up sonarqube server below:
I set up sonarqube 6.7.7 to localhost
I added to fxcop plugin 1.4(https://community.sonarsource.com/t/new-release-fxcop-plugin-version-1-4/1430)
I created fxcop custom rule template on sonarqube quality profiles
I've written below
Name : SampleCustomRule
Key : SampleCustomRule
Description : SampleCustomRule
CheckId : SK100
I activated this rule on sonarqube rules
Second, I created sample fxcop custom rule(Visual Studio) below:
I referenced this video.(https://www.youtube.com/watch?v=arHybNYWj04)
Create Class Library
Add References(FxCopSdk, Microsoft.Cci)
Create Sample rule .cs & rules.xml
Create sign file(.pfx)
Build project
copy my assembly(.dll) to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\Rules
Third, I executed MSBuild(SonarScanner)
run as administrator(Developer Command Prompt for VS 2019)
I entered command below
SonarScanner.MSBuild.exe begin /k:"ConsoleApp10" /n:"ConsoleApp10" /v:"3.6" /d:"sonar.cs.fxcop.assembly=C:\Users\ezcare\Desktop\FxCopTest\FxCopTest\bin\Debug\FxCopTest.dll" /d:"sonar.cs.fxcop.fxCopCmdPath=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe" /d:"sonar.cs.fxcop.directory=C:\Users\ezcare\Desktop\FxCopTest\FxCopTest\bin\Debug"
MSBuild.exe C:\Users\ezcare\source\repos\ConsoleApp10 /t:Rebuild
SonarScanner.MSBuild.exe end
The result was successed.
I checked the project which is inspected as my custom rule, but There wasn't any code smell or something.
below is my custom rule code(.cs & .xml)
using Microsoft.FxCop.Sdk;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
[assembly: CLSCompliant(true)]
namespace FxCopTest
{
public class SampleCustomRule : BaseIntrospectionRule
{
public SampleCustomRule():
base(#"SampleCustomRule", "FxCopTest.Rules", typeof(SampleCustomRule).Assembly)
{
}
public override ProblemCollection Check(TypeNode type)
{
if(!type.Namespace.Name.StartsWith("SK", StringComparison.Ordinal))
{
var resolution = GetResolution(type.Name.Name);
var problem = new Problem(resolution, type)
{
Certainty = 100
//FixCategory = FixCategories.NonBreaking,
//MessageLevel = MessageLevel.Warning
};
base.Problems.Add(problem);
}
return base.Problems;
}
}
}
<?xml version="1.0" encoding="utf-8" ?>
<Rules>
<Rule TypeName="SampleCustomRule" Category="CustomRules.Naming" CheckId="SK100">
<Name>All type namespace should start with 'SK'</Name>
<Description>SK</Description>
<Resolution>The name of type {0} should start 'SK'</Resolution>
<MessageLevel Certainty="100">Warning</MessageLevel>
<FixCategories>NonBreaking</FixCategories>
<Url/>
</Rule>
</Rules>
I wouldn't recommend writing new rules for C# or VB.NET using FxCop, particularly if you want to import issues into SonarQube.
Firstly, FxCop was replaced by the more powerful and easier to use Roslyn framework several years ago. Writing custom rules in Roslyn is simpler and there are many resources on the web to help you e.g. Getting Started with Roslyn Analyzers (if you've managed to write a custom rule in FxCop then you'll have no problem writing one using Roslyn!).
Secondly, SonarQube and the Scanner for MSBuild provide out-of-the-box support for importing issues from custom Roslyn analyzers as "external issues". Basically, that means if you package your new Roslyn analysis rules as a NuGet package then reference that NuGet package in the project you want to analyse, the Scanner for MSBuild will automatically upload the issues to SonarQube.
However, external issues have a few limitations as described in the SonarQube documentation - you can't configure the rules to be executed in the Quality Profile, you can't mark issues as false positive etc in the UI, and you are responsible for adding the custom Roslyn analyzer NuGet package to all of the MSBuild projects you want to analyse.
To get round all of these limitations, you can use the SonarQube Roslyn SDK to generate a custom SonarQube plugin jar that packages up your custom Roslyn analyzer. You don't need to write any code; just run RoslynSonarQubePluginGenerator.exe against your Roslyn NuGet package and it will create a plugin jar.
Once you install that generated custom SonarQube plugin into your SonarQube instance, you will be able to configure your rules in the Quality Profile, mark issues as FPs etc, and the Scanner for MSBuild will take care of executing your analysis rules as part of the build so you don't need to reference your custom Roslyn analyzer NuGet package from every MSBuild project you want to analyse.
I'm attempting to use the build system in VSTS to build and deploy a c# .net web app. I've created a new single-project solution (as there doesn't seem to be any way to specify which project to build/deploy in a multi project solution!?!) and set up my build definition to point to this new solution. I've set it up to use the VS2017 build agent.
The NuGet restore completes and it begins to build but fails with the error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeployPackage.targets(124,7): Error MSB4184: The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form.
Has anyone encountered this and knows how to fix it?
Thanks
I know this might be bit late, but if it helps anyone then they should install the extension VSColorOutput
Then go to Tools => Options => VSColorOutput => General => Set Stop Build on First Error to true.
Using .Net Core step/task instead. (Command: publish; Arguments: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory))
Similar issue: VSTS fails to build my really really simple ASP.NET Core app
I am trying to analyse a solution with Roslyn, with MSBuildWorkspace.
The solution is a new solution, with 2 class library projects in them, one referencing the other.
They are created in Visual Studio 2017, .Net 4.6.2.
When I open the solution, I receive two generic errors in workspace.Diagnostics, both are :
Msbuild failed when processing the file 'PathToProject'
There is nothing more in the diagnostics or output window, to indicate WHY it failed to process the project file.
The code for opening the solution:
namespace RoslynAnalyse
{
class Program
{
static void Main(string[] args)
{
LocalAnalysis();
}
private static void LocalAnalysis()
{
var workspace = MSBuildWorkspace.Create();
var solution = workspace.OpenSolutionAsync(#"D:\Code\Roslyn\RoslynAnalyse\SolutionToAnalyse\SolutionToAnalyse.sln").Result;
var workspaceDiagnostics = workspace.Diagnostics;
}
}
}
The version of Microsoft.CodeAnalysis is 2.0.0.0.
Does anybody have any idea why MSBuild failed, how I can get more information ?
When MSBuildWorkspace fails to open a project or solution this way, it is almost always because the application using MSBuildWorkspace does not include the same binding redirects that msbuild.exe.config has in it.
MSBuild uses binding redirects to allow tasks (typically already compiled C# code using possibly different versions of msbuild API libraries) to all use the current msbuild API's. Otherwise, msbuild gets runtime load failures.
The solution is to add an app.config file to your project and copy the binding redirects (the assemblyBinding section of the msbuild.exe.config file) into your file.
We're asked to move from NUnit to MSTest and now have to convert all the existing tests to the new platform. Most of it converted fine but we have an issue with parameterised tests. We found the following web site showing how to write an extension and downloaded the code for it.
http://blogs.msdn.com/b/vstsqualitytools/archive/2009/09/04/extending-the-visual-studio-unit-test-type-part-2.aspx
However, although it compiles fine, the RowTestClass test all fail to run with the following error message:
"Failed to initialize the unit test extension 'urn:RunAsTestClassAttribute': A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.Test.Sample.UnitTestTypeExtension.RunAsSample.RunAsTestClassAttribute."
We're using VS2010 (10.0.40219.1 SP1Rel) (Microsoft .NET Framework Version 4.0.30319 SP1Rel)
I wonder if it has something to do with the following libraries:
Microsoft.VisualStudio.QualityTools.Common.dll
Runtime Version: v2.0.50727
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.QualityTools.Common.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Runtime Version: v4.0.30319
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Microsoft.VisualStudio.QualityTools.Vsip.dll
v4.0.30319
C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.Vsip\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.Vsip.dll
Any help to get this working greatly appreciated.
Have you registered the new types (in the Windows Registry)? There's a section on how to do it in the tutorial - have a look at Row Test Test Type Extension: Registering your test type extension.
If you're having trouble, try downloading the complete code + registry keys from the MSDN code gallery.
You may want to look into using SpecFlow to make your tests more parameterized. It is traditionally a BDD tool, but it will allow you to make re-usable steps that take parameters.
For example you can create a step saying
"Given the user 'admin' exists."
and on the c# side you get a method like this:
[Given(#"the user '(.*)' exists"]
public void GivenTheUserExists(string name)
{
//create the user
}
Going forward you can reuse the step in any "feature file" without having to rewrite the implementation of that step.
Just refer to the blog post Extending Unit Tests in Visual Studio. And see what you might have missed. I tried the same, and it works well for me.