Unable to create packages for a Dot Net Core project using 4.7 framework. I am using msbuild /t:pack /p:COnfiguration=Release command in teamcity to create a package.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net471</TargetFramework>
</PropertyGroup>
</Project>
NuGet.Build.Tasks.Pack is installed in the project.
we use only .net core csproj structure but not .net core as target framework so it can't be compiled via .net CLI - that's why we build projects via MSBuild and not .net CLI
Please guide how to create packages for such project.
Seems that the way TeamCity operates with msbuild, by default it creates a wrapper script and then calls that. Something in the way the wrapper opperates prevents it from working properly.
At the TeamCity MSBUILD Docs there is a note on Implementation Note that you can disable the wrapper. I tried this and it seemed like it works.
To disable the wrapper behaviour teamcity.msbuild.generateWrappingScript to false.
I did this by adding teamcity.msbuild.generateWrappingScript as a configuration parameter on the build config with the value "false". Then I re-ran the build and it behaved as expected.
Related
I have a solution of a hundred plus .NET Core projects. Not all of them needs to be packed, but only those which are transitive dependencies of a few special projects.
However, when I run dotnet pack it attempts to pack all kinds of projects that it should not and there are errors here and there. I would like instead to run pack on the special projects only in a recursive fashion, so that only them and their transitive dependencies (project references, of course) are packed.
I figured I can implement it by scripting around the dotnet list reference command, but it does not sound right. There must be a better way to do it.
EDIT 1
The solution must work on the command line where we have dotnet and msbuild and possibly nuget, but no VS IDE.
You can modify your project settings to generate *.nupkg file during dotnet build, without explicit dotnet pack call. And as soon as dependencies get builded automatically when "parent" project builds - you will receive nuget packages prepared for all dependencies too when you run dotnet build for "parent" project only.
For each project that should produce nuget package add this lines into csproj file:
<PropertyGroup>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
Or, instead, you may enable checkbox "Generate NuGet package on build" from Visual Studio, in project properties ("Package" tab) - this will add same line into project file.
I want to know the exact dotnet cli commands that Visual Studio uses when I Build/Rebuild and Clean solution in my dotnet core application?
I know that the dotnet core cli was build on top of msbuild so when you run Build/Rebuild or Clean Solution Visual Studio uses
msbuild commands directly and not the ones from dotnet core cli?
Is that correct?
If this is correct I would like to know which msbuild command or commands it uses with the three actions:
Build Solution
Rebuild Solution
Clean Solution
And which dotnet core cli commands would be equivalent to that?
I know from this post(Relationship between the dotnet cli and the new vs2017 msbuild)
that the following commands do the build, rebuild and clean in dotnet and msbuild.
Dotnet cli:
Build: dotnet build
Rebuild: dotnet build --no-incremental
Clean: dotnet clean
Msbuild:
Build: msbuild /t:build
Rebuild: msbuild /t:rebuild
Clean: msbuild /t:clean
I guess this is not all? This is fine but I would like to see what Visual Studio produces for the actions?
And I am wondering if Visual Studio behavior can be changed so it runs dotnet cli commands instead of msbuid?
Research:
I was building a asp.net core web api project in Visual Studio(Visual Studio 2017 Enterprise Version 15.9.11)
I was looking in Visual Studio Output when I Build/Rebuild and Clean the solution but I could not find anything related to
dotnet core cli or msbuild. Then I went to VisualStudio Tools/Option/"Project and Solution"/"Build and Run" and changed the options:
MSBuild project build output verbosity: tried both "Detailed" and "Diagnostics" options
MSBuild project build log file verbosity: tried both "Detailed" and "Diagnostics" options
The outcome was that the log that was produced in the Output window of Visual Studio was huge and it was difficult to find
the exact command which would be used for the actions. I can see msbuild used in many places in the output but it is a little confusing
to find the exact command.
I also saw this question (Does Visual Studio use MSBuild internally, and what is the exact command?)
This answer says that:
Quote:
"It appears that the MSBuild command line options are not specified,
but rather the MSBuild APIs are called within Visual Studio. Unless
you have the Visual Studio source code to reverse engineer, you cannot
get an equivalent command line."
Is that the same case for dotnet core cli msbuild as well?
Any help or clarification on this is appreciated.
I know that the dotnet core cli was build on top of msbuild so when
you run Build/Rebuild or Clean Solution Visual Studio uses msbuild
commands directly and not the ones from dotnet core cli?
For VS2017, I would think the VS IDE calls msbuild.exe directly when Clean, Build and Rebuild.You can easily check this point by Task Manager or Process Monitor.
As for what you mentioned above:It appears that the MSBuild command line options are not specified, but rather the MSBuild APIs are called within Visual Studio.
I think it's right but only for the eariler vs versions(2010,2013). I've tested with VS2010, when doing building-related actions in VS, it doesn't call MSBuild.exe. So the msbuild in VS2010 is not executed as a separate process.
But for VS2017, when I create projects which target .net core, when doing building-related actions(click the build, clean, rebuild button), it obviously calls the msbuild.exe like below:
About what msbuild commands VS actually executes:
Since now the VS2017 calls msbuild.exe to build .net core or .net fx projects.
In my opinion:
For the solution which only contains a project:
Build the Solution=> msbuild xxx.sln /t:build /p:Configuration=xxx;Platform=xxx
Rebuild the Solution=>msbuild xxx.sln /t:rebuild /p:Configuration=xxx;Platform=xxx=>msbuild xxx.sln /t:clean;build /p:Configuration=xxx;Platform=xxx
Clean the Solution=>msbuild xxx.sln /t:clean /p:Configuration=xxx;Platform=xxx=>msbuild xxx.sln /t:clean
I think every time when we click Build button in VS, it will pick the value of Configuration and Platform from this box, because these two parameters are sure to be passed to MSBuild.exe.
Also, one thing we can discover is that IDE has a check process before start build: It will check if the file is out-of-date and then determine if it need to build or not. But this is not what you ask in your issue and it not affects the command you want, so I skip it.
Also, see this page we can find there are some msbuild-related settings here:
So actually I think the command above should add some parameters like:msbuild ... -m:8 -v:M.
In addition: Though I find building-related action in VS will call msbuild.exe directly. I'm not certainly sure that my command above is 100% correct. I'm afraid no one can ensure that except the guys who develop the menu command in VS IDE. So if i misunderstand anything please feel free to correct me:)
And if you just want to get the exactly same thing like what in VS, you can also have a try devenv.exe. This is the only place in official document which confirms the build switch performs the same function as the Build Solution menu command within the integrated development environment (IDE).
My setup is: I have a solution that had different dotnet4.6 applications (services) in it. Now we added a dotnet core project inside this solution. I can build and debug it, but this doesn't create an executable. In Visual Studio I can rightclick -> Publish... it. I created two profiles (x86 and x64) that should create nice binaries in /bin/Publish/x86 or /x64. In VS this works. The application is self-contained and works on different unprepared machines.
But now I Need to move that process to the buildserver. I messed around with dotnet publish but in the end i get stuck because other components of the solution are not clean dotnet core and so the build fails.
So I need to stick with MSBuild.
The current attempt is:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe" NewProject\NewProject.csproj /p:DeployOnBuild=true /p:UsePublishProfile=true /p:PublishProfile=x64Profile.
This says it finished building successfully, but I don't see any results. Also it doesn't make any difference, if I remove all properties and just call msbuild and *.csproj. It just builds the new project in bin/Debug, as dll, not exe.
I also messed around with p:PublishProfile="NewProject\Properties\PublishProfiles\x64Profile.pubxml" and /p:PublishUrl="NewProject\bin\Publish\x64" but it doesn't change anything.
I read a few articles on SO, telling that VS doesn't just call msbuild with parameters but does internal API calls. Still, I need a solution. I need the build server to create an executable. Is there a way to trigger msbuild to create thath?
Oh man, I searched for 2-3 days now. And - as always on StackOverflow - shortly after asking I found a working answer myself.
tl;dr:
Project.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp2.1</TargetFrameworks>
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<RootNamespace>Company.Toolset.Exporter</RootNamespace>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" />
...
MSBuild command:
msbuild Project\Project.csproj -t:restore /t:Build;Publish /p:Configuration=Release /p:Platform=x86 /p:PublishProfile=x86Profile /p:OutputPath=bin/Publish/x86 (and the same for x64)
Explanation:
I think it was the dotnet build/publish command that wanted me to change TargetFrameworks to TargetFramework. But for MSBuild this is wrong. And dotnet wasn't working here, as the solution is mixing dotnet core and dotnet framework. So that had to be fixed.
The <RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers> was needed by the command. I added it to the *.csproj because I know that I build for windows only (at the moment) and that I need both versions.
I don't really know why I needed this line <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" /> but without this publishing and using the PublishProfiles didn't work as expected.
Links that helped me to get here: (not sorted)
https://github.com/Microsoft/msbuild/issues/1901
https://github.com/aspnet/vsweb-publish/issues/22
How to Publish Web with msbuild?
ASP.NET Core Application (.NET Framework) for Windows x64 only error in project.assets.json
Configure MSBuild output path
I too had a nightmare with inconsistencies between builds from Visual Studio IDE and the dotnet publish command, that were only fixed by doing it using msbuild.exe instead. Also, using /p:PublishProfiles=theXMLthatVSgenerates.xml never worked, so I had to break out every option into the msbuild command line.
Here's what worked for me:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\msbuild.exe" C:\Users\xxxx\Source\Repos\netcore-agent1\CoreAgent1\CoreAgent1.csproj /t:Restore;Rebuild;Publish /p:PublishSingleFile=True /p:SelfContained=True /p:PublishProtocol=FileSystem /p:Configuration=Release /p:Platform=x64 /p:TargetFrameworks=netcoreapp3.1 /p:PublishDir=bin\Release\netcoreapp3.1\publish\win-x64 /p:RuntimeIdentifier=win-x64 /p:PublishReadyToRun=False /p:PublishTrimmed=False
I work with .NET Core SDK version 2.1.302. My solution has two type of projects: libraries and web. All libraries are targeted to .NET Standard 2.0: <TargetFramework>netstandard2.0</TargetFramework> and web projects have multiple targets: <TargetFrameworks>net462;netcoreapp2.0</TargetFrameworks>
I have two CI builds: for Windows which uses net462 and build in docker based on linux with netcoreapp2.0.
In the docker build to build my solution I use the following line of code:
RUN dotnet build ./MySolution.sln --configuration Release --framework netcoreapp2.0
And build fails with the rrors like this:
Assets file '/app/MyLibraryProject/obj/project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. [/app/MyLibraryProject.csproj]
It happens because as I mentioned before my library projects are targeted only one framework - netstandard2.0
So, my question is how to deal with this situation? How should I specify that projects with only one target framework should ignore --framework param?
In the interests of making sure the answer is noticed, I found that the best way around this was #José Pedro's solution from the above comment stream.
In the csproj file, I put a condition on the TargetFramework element. Now it looks as follows:
<TargetFrameworks Condition="'$(CoreOnly)' != 'True'">net472;netcoreapp2.1</TargetFrameworks>
<TargetFramework Condition="'$(CoreOnly)' == 'True'">netcoreapp2.1</TargetFramework>
It will then by default compile both, but you can pass a CoreOnly parameter to only compile the .NET Core framework.
dotnet build MySolution.sln /p:CoreOnly=True
Another possible solution is to check which framework is available and set the <TargetFramework> dynamically in the build time:
<FrameworkDescription>$([System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription)</FrameworkDescription>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 5'))">net5</TargetFramework>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 7'))">net7</TargetFramework>
It will make dotnet build just work without any additional parameters on a system where only net5 or only net7 is installed.
I'm trying to integrate static analysis on a .net core 1.1 project. What I did until now is install the Microsoft.CodeAnalysis.FxCopAnalyzers nuget and added the rules in the csproj under property group:
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
<CodeAnalysisRuleSet>../StaticAnalysis/ManagedRuleSet.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
I've created a rule violation to test, and the setup works well in Visual Studio 2017. The problem comes when I try to build from the console:
dotnet build
No errors or warnings :( This is crucial to get so I can make this run on the build machine as well.