I have a dotnet SDK .sln (and a build.proj) with <TargetFrameworks>netcoreapp2.1;net461</TargetFrameworks>. It builds on Windows using Visual Studio and dotnet build, but I'd also like it to build as many other places as possible. What do I need to put in my README.md and/or what can I put in the project files to make it build on Rider and/or on from bash on a Mac?
(using .NET Core SDK) The simplest way to build for a .NET Framework TFM when running on either macOS or Linux using the .NET Core CLI, is to utilize the .NET Framework Targeting Pack Nuget Packages from Microsoft (currently in preview):
These packages enable building .NET Framework projects on any machine with at least MSBuild or the .NET Core SDK installed.
The following scenarios and benefits are enabled for .NET Framework projects:
Build without requiring admin operations to install pre-requisites such as Visual Studio or .NET Framework targeting packs.
Build libraries on any operating system supported by the .NET Core SDK.
Build Mono-based projects.
You may either include the Microsoft.NETFramework.ReferenceAssemblies metapackage;
or use just the specific package, which is in your case Microsoft.NETFramework.ReferenceAssemblies.net461.
Add the package to the *.csproj or your Directory.Build.props:
<Project>
<ItemGroup>
<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
</ItemGroup>
</Project>
Note: The PrivateAssets attribute controls which dependency assets will be consumed but won't flow to the parent project. See the docs.
Update
This is no longer required using the .NET 5 SDK (e.g. 5.0.100), which will now automatically add the PackageReference to the ReferenceAssemblies for .NET Framework.
In order to build via bash on a vanilla Mac, the minimal steps seem to be:
Install Mono 6.0 (5.2 is recommended for VS Mac interop, I dont care about that, and Mono 6.0's interop with Dotnet core is better)
Install dotnet SDK 2.2 (doesn't have to be exactly that, but it works for me)
Put this in a Directory.build.props file (open to improvements if anyone has any)
<Project>
<PropertyGroup>
<IsOSX Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::OSX)))'== 'true'">true</IsOSX>
</PropertyGroup>
<PropertyGroup Condition=" '$(IsOSX)' == 'true' ">
<FrameworkPathOverride>/Library/Frameworks/Mono.framework/Versions/Current/Commands/../lib/mono/4.6.1-api</FrameworkPathOverride>
</PropertyGroup>
</Project>
Bash: dotnet build SolutionFileName.sln should now work
Install Rider 2019.1 or later
Rider: should Just Work (it should autodetect msbuild 16.0 in the build tools section)
Related
I have two .net core applications running on Linux.
One of them is happy with .net core runtime while another one is demanding .net core SDK.
I can build both applications using dotnet publish with the following parameters:
dotnet publish Web/Web.csproj -o publish -c Release -r linux-x64 --self-contained false
Both projects target 3.1 (checked .csproj):
<TargetFramework>netcoreapp3.1</TargetFramework>
I am deploying them to the same VM server which has .net 3.1 runtime installed:
.NET Core SDKs installed:
No SDKs were found.
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
However, on start of one of those projects as systemctl service I am getting an error:
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download
While I can successfully start the application manually using dotnet Web.dll
Does my build artifact requires SDK?
Any ideas how can I troubleshoot this behavior?
1- No, it shouln't require SDK
2- Hard to help you with the incomplete question
Have you tried to run the service with SDK installed? To check if that is the actual problem or just a misleading error.
Are you using Systemd integration package by Microsoft?
dotnet add package Microsoft.Extensions.Hosting.Systemd
We developed an a .NET Core Web API application using the following technologies:
-NET Core (3.1)
-Visual Studio 2019
Unfortunately, we have to deploy said application to the following environment:
-32-bit Environment
-Windows Server 2008 R2 Enterprise (Service Pack 1)
-IIS Version 7.5
-8 GB RAM
Therefore, within my Visual Studio 2019, I brought up the application, and took the following steps:
Force x86 in VS go to the Properties > Build and change Platform target from Any CPU to x86
Created a Directory.Build.targets in the the .NET Core application's Project root directory:
<Project>
<PropertyGroup
Condition="'$(OS)' == 'Windows_NT' and
'$(PlatformTarget)' == 'x86' and
'$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
'$(SelfContained)' != 'true'"
>
<RunCommand>$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>
</PropertyGroup>
< /Project >
From Visual Studio 2019 Developer Command Prompt v16.4.6, I navigated to the .NET Core application's Project root directory.
I ran:
>
>
dotnet clean
...........................
.............
dotnet build
C:\Program
Files\dotnet\sdk\3.1.101\Microsoft.Common.CurrentVersion.targets(2726,5):
error MSB4216: Could not run the "ResolveComReference" task because
MSBuild could not create or connect to a task host with runtime "CLR4"
and architecture "x86". Please ensure that (1) the requested runtime
and/or architecture are available on the machine, and (2) that the
required executable "C:\Program Files\dotnet\sdk\3.1.101\MSBuild.exe"
exists and can be run.
[D:\ blah blah.csproj]
6 Warning(s)
1 Error(s)
Time Elapsed 00:00:04.63'
Could someone please tell me how I can build and run this application in a 32-bit environment?
What steps should I take to build and run .net core Web API
application in 32-bit environment/runtime?
It is quite strange. First, just as akseli and omajid said, try to install Net Core 3.1 x86 sdk version.
Then, try the following steps:
Steps
1) change build platform target to x86 in 32-bit environment.
2) when you migrate the project into 32-bit environment, please delete .vs hidden folder which exists under the solution folder, bin, obj folder.
3) open Developer Command Prompt for VS2019 in 32-bit environment(it call the msbuild.exe under C:\Program Files\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe) to build your project.
4) try to use msbuild rather than dotnet build since MSBuild is more powerful and has a wider range of compilations.
msbuild xxx.csproj -t:build
msbuild xxx.csproj -t:clean
4) or add these node in your xxx.csproj file then build your project
<PropertyGroup Condition="'$(MSBuildRuntimeType)' == 'Core'">
<GenerateResourceMSBuildArchitecture>CurrentArchitecture</GenerateResourceMSBuildArchitecture>
<GenerateResourceMSBuildRuntime>CurrentRuntime</GenerateResourceMSBuildRuntime>
</PropertyGroup>
Any feedback will be expected.
#akseli #omajid #perry-qian-msft #yongqing-yu Sorry, this failed to work, we had to move away from using .NET Core technology( and had to migrate over to .NET Framework 4.7.2) because it would work properly for a little while, and then give us 500 error, and then later some 401 error. I think it has something to do with the configuration because we are using:
-NET Core (3.1)
-In-Process within IIS Server
therefore, Within the standalone IIS Server, we should Not have to run the .NET Core (3.1) application within it's own application pool as "Not Managed Code" because it's all In-Process and .NET Core (3.1) can run on IIS. In any case, we do Not have time to resolve this problem so we migrate over to .NET Framework 4.7.2
#akseli #omajid #perry-qian-msft #yongqing-yu All Thank you for all your responses.
My Team Tech Lead found the solution by specifying the .NET Core Web API Application's Build Settings to "Any CPU" Within Visual Studio 2019. ( Within Visual Studio 2019, Right-click on .NET Core Web API Application, and then choose properties from the drop-down context menu, and then when the window pane shows up on, you select the Build Tab. )
Also, on the IIS Server, my Team Tech Lead ensured that that deployed .NET Core Web API Application's Application pool had the following settings( important to keep in mind that it is "Not Managed Code":
I am having a hard time deploying my first .net core app with nuget references on the server. Locally, the app works absolutely fine (able to use nuget packages).
Apparently, there is no packages.config. I am using Dapper, Newtonsoft.Json, etc. Where is the project storing reference to these packages? There is no packages folder.
In the solutions folder, there is nuget.config file which for some reason is empty.
What should I add here
Unable to deploy app with nuget references on server
That because you are using the old version nuget restore task in the build pipeline, which only supports for the package management type packages.config not PackageReference.
That the reason why the old version task ask you to provide the path to the packages.config. The PackageReference is a follow-up product, so the previous version of nuget restore task does not support it.
Check the blog for some more details.
To resolve this issue, please use the V2 of the nuget restore task:
Note:
The PackageReference needs the nuget.exe 4.1 and above, please add
a NuGet tool installer to install the nuget version above 4.1.
Using .NET Core restore task should be also work for this issue.
Update:
Yes, using TFS 2016
Since you are using TFS 2016, you could try to use the command line to invoke the nuget.exe to restore the package instead of the nuget installer task:
Download the nuget.exe above 4.0 from the nuget.org, then set it on the TFS server.
Hope this helps.
You need to create a NuGet.config file that points to whatever NuGet feed you're using, add it to source control, and reference it in your build. I'll use the official feed for my example. This feed is already present by default if you're developing using Visual Studio, which might explain why the build runs locally but not on Azure DevOps.
At the very least, your NuGet.config file needs to look like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="NuGet.org Feed" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
In .NET Core, packages are now stored globally in your User directory. packages.config has been dropped in favor of the PackageReference node in a project file, so check your csproj to see the NuGets you're referencing.
You should use task dotnetcorecli task which has
#command: 'build' # Options: build, push, pack, publish, restore, run, test, custom
When publishing an ASP.NET Core application to a Linux server running nginx, is it necessary to install the .NET Core runtime on the server?
One of the options when publishing a .NET Core application is self contained deployments which include a version of the .NET Core runtime.
They are described (in the above link) as:
For a self-contained deployment, you deploy your app and any required third-party dependencies along with the version of .NET Core that you used to build the app. Creating an SCD doesn't include the native dependencies of .NET Core on various platforms, so these must be present before the app runs.
So your target machine will still need to have the libraries that .NET Core relies on, but it's entirely possible to publish you application and not have the .NET Core runtime installed on your target server.
Creating a SCD, you need to make a few changes to your csproj
<PropertyGroup>
<RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
</PropertyGroup>
The above would inform MSBuild that you want to target 64 bit Windows 10 and OSX 11.10.
Then you can create a published version of your app for one of those run platforms by running the following commands:
dotnet publish -c Release -r win10-x64
dotnet publish -c Release -r osx.10.11-x64
(the first line creates a SCD for Windows 10 64 bit, and the second does the same for OSX 10.11 64 bit.
Source: Self-contained deployment without third-party dependencies
Please see Solution section below for the TLDR.
I used the Visual Studio 2015 Community edition and upgraded to Visual Studio 2017. I am developing a .NET Core console application. I am talking here only about my local development machine, which has Visual Studio installed and it has .NET Core runtimes and SDKs installed.
In Visual Studio 2015, project.json files were used, and by default the build process produced a DLL file in the bin/Debug/netcoreapp1.1, that one could run using the dotnet run command. But there was an option to make a minor tweak in the project.json file:
...
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
...
->
...
"Microsoft.NETCore.App": {
"version": "1.0.1"
},
...
And adding a runtimes section, such as
"runtimes": {
"win10-x64": {}
}
And if you did this and built your project, an EXE file was created that you could run directly, without using dotnet run.
Now the question is, is the same possible in Visual Studio 2017 using .csproj XML files? And more specifically, is it possible without the heavy self-contained deployments? I do want it without the full SDD publish because I use these executables for just local testing during the development. Once the project is to be released, I do the SDD publish, but that is very inconvenient during the development process.
The project was converted to Visual Studio 2017, but it only generates DLL files again. So, I tried to create a completely new and empty Hello, World! program and try to get EXE file from it. The Hello, World! csproj file looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
This only generates a DLL file that you can run with dotnet run. It is possible to make a change to this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp1.1;net46</TargetFrameworks>
</PropertyGroup>
</Project>
which is very close to what I want - generating an EXE file. However, this creates EXE file that runs .NET Framework 4.6, not .NET Core. So, it does not solve the problem. What I really want is .NET Core executable without having to do self-contained deployment. Is it possible?
Solution
I just found out that this is indeed possible. I just don't know how to do it in the IDE. What currently happens if I hit Ctrl + Alt + F7 in the IDE produces the same result as the command:
dotnet build --configuration Debug
And what I want can be produced by command:
dotnet build --configuration Debug --runtime win10-x64
So what I really want now is modify the default IDE build command to replicate this behavior with --runtime win10-x64 parameter.
In .NET Core, if you want an .exe produced during dotnet build, you need to supply the runtime that you want the executable built for.
In project.json, you did it as you describe above by removing type: platform and adding a runtimes section.
In .csproj, you do it by specifying the MSBuild property named RuntimeIdentifier. On the command-line, when you say dotnet build --runtime win10-x64, the --runtime value gets passed into MSBuild has the RuntimeIdentifier property.
One option is you can purely set the RuntimeIdentifier in your .csproj:
<PropertyGroup>
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
</PropertyGroup>
Now when you build in Visual Studio, it will produce an .exe in the build output folder.
Alternatively
I'm not sure if you are interested in this or not, but it sounds like you just want a way to run your application without calling dotnet run. If this is true, you don't need to set a runtime at all. By default your application gets built into bin\Debug\netcoreapp1.1\AppName.dll. You can run your application by saying dotnet bin\Debug\netcoreapp1.1\AppName.dll, which is basically what dotnet run does under the covers.