SonarQube has an MSBuild runner but .NET Core uses dotnet.exe to compile and msbuild just wraps that. I have tried using the MSBuild runner with no success against my ASP.NET Core solution. Using SonarQube Scanner works kind of.
Any suggestions on how I can utilize SonarQube with .NET Core? The static code analysis is what I am looking for.
With .csproj now being the de-facto format of .Net Core solutions, SonarQube support of such solutions comes with the SonarQube Scanner for MSBuild v2.3 .
It seems .NET Core is switching from project.json to use .csproj and MSBuild. That may be available in .NET Core 1.1 or similar. At that time it may be possible to use MSBuild to build projects and have SonarQube pick that up.
See: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/
Whether that be a good thing or not remains to be seen I guess.
Also see this link for a possible workaround to use MSBuild to build .NET Core projects in the meantime (I have not tested it yet): https://learn.microsoft.com/en-us/dotnet/articles/core/tutorials/target-dotnetcore-with-msbuild
The .NET Core tooling is going to move from project.json to MSBuild based projects. We expect the first version of the .NET Core tools that use MSBuild to ship along with the next version of Visual Studio. However, it is possible to use MSBuild for .NET Core projects today, and this page shows how.
I was able to get .NET Core builds working from the procedure on their site, with two things I'd like to point out….
When you run the SonarQube.Scanner.MSBuild.exe command lines, you must be in the same directory as your project file, and the location directory of the end command must match the start.
When the instructions say you must modify sonar.host.url to point to your server, you must uncomment the entire section of the file before doing the modification. Otherwise you've just inserted your server into a sonar.host.url line that is dead because it is commented out. This made me spin for a while before I really looked….
Related
There are plenty of reported bugs in almost every version of Visual Studio with similar or exactly the same issue. The problem is that every bug report I found has been already resolved. Additional info: My exact same code has worked a month ago. I am using .NET Core 3.1.100 and Visual Studio 16.4.2.
Project GUI
.csproj Configuration
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Demo|AnyCPU'">
<DefineConstants>DEMO</DefineConstants>
</PropertyGroup>
Code (as you can see, the DEMO symbol will not be applied).
Has anyone an idea how to hotfix this issue for my production environment?
Thanks in advance!
This is not how this should be done in ASP.NET Core. ASP.NET Core doesn't use the concept of build configurations natively, and while you can sort of use them in places like this or compiler directives, it goes against the grain of ASP.NET Core app design. ASP.NET Core apps are build once, deploy anywhere, in contrast to ASP.NET where you needed to build for each environment separately.
Instead, this should be handled via config and environments. You can even have a "Demo" environment, if you like, which would then allow you to just inject IWebHostingEnvironment and check _env.IsEnvironment("Demo"). Short of that, you should simply specify via config (JSON, environment variable, etc.) a "Demo" boolean, and then pull that out of IConfiguration.
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.
I am following this guide to installing and using MSpec, but at the step where he runs MSpec for the first time, I get the following error:
Could not load file or assembly 'file:///[...]\Nehemiah\Nehemiah.Specs\bin\Debug\Nehemiah.Specs.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
I have - to my knowledge - done everything more or less exactly like he did up to this step, except where differences arise because he's using VS2008 and I'm using VS2010, and everything has worked so far. The project Nehemijah.Specs (and the entire solution) builds without problem, both in Visual Studio and on my build server, and I can't find anything useful in Event Viewer (although I might not be looking in the right place here...)
What to do?
It appears you're compiling the Nehemiah.Specs.dll assembly against the .NET Framework 4. In order to run your specifications you need the .NET 4 build of MSpec which contains a console runner (mspec.exe) that is suitable for this version of the framework. You can find the a zip file containing the build on CodeBetter's CI server.
Other possibilities of running .NET 4 spec assemblies are
TestDriven.Net 3.0
ReSharper 5.0
Runners for both tools are also included in the distribution.
I’m working on the build process for a VS 2010 solution and some projects within it target the .NET framework 4.0. As far as I know, to have this type of solution built by TFS 2008 we will have to change the version of the MSBuild.exe file used by the build agent – modifying the TFSBuildService.exe.config file, pointing MSBuildPath entry accordingly.
Do you know if this will have any impact to existing project builds that target the 2.0 and 3.5 framework? Are you aware of any known issues with this type of set up?
We made such upgrade from VS2008 to VS2010 without the TFS migration (so it's still in 2008 version). Only problem we had was with build machine (cause we have only one) so we had to configure SideBySide builds. We had projects in VS2008 solution with MSBUILD scripts, some of them were migrated to VS2010.
Here's the solution http://www.codeproject.com/KB/architecture/SideBySideTfsBuild.aspx
After changing we didn't experience any problems, yet:)