I've updated all projects in my solution to use .net6, and have updated nswag json file to runtime to Net60.
I have .net 6.0.100 installed.
Here is the build output
$ dotnet build Solution.sln
Microsoft (R) Build Engine ersion 17.0.0+c9eb9dd64 for .NET
Restored C:\src\...\Client.csproj (in 455 ms).
NSwag command line tool for .NET Core Net60, toolchain v13.15.10.0 (NJsonSchema v10.6.10.0 (Newtonsoft.Json v13.0.0.0))
NSwag bin directory: C:\Users\...\.nuget\packages\nswag.msbuild\13.15.10\tools\Net60
Executing file 'nswag.json' with variables 'Configuration=Debug'...
C:\Program Files\dotnet\sdk\6.0.100\Microsoft.Common.CurrentVersion.targets(1217,5): error MSB3644: The reference assemblies for .NETPlatform,Version=v6.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks [C:\src\API.csproj] [C:\src\...\.Client.csproj]
System.InvalidOperationException: Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core project.If you're using custom BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use the --msbuildprojectextensionspath option.
at NSwag.Commands.Generation.AspNetCore.ProjectMetadata.GetProjectMetadata(String file, String buildExtensionsDir, String framework, String configuration, String runtime, Boolean noBuild, String outputPath, IConsoleHost console) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/ProjectMetadata.cs:line 152
C:\src\....Client.csproj(15,5): error MSB3073: The command "dotnet "C:\Users\...\.nuget\packages\nswag.msbuild\13.15.10\build\../tools/Net60/dotnet-nswag.dll" run nswag.json /variables:Configuration=Debug" exited with code -1.
C:\Program Files\dotnet\sdk\6.0.100\Microsoft.Common.CurrentVersion.targets(1217,5): error MSB3644: The reference assemblies for .NETPlatform,Version=v6.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks [C:\src\API.csproj] [C:\src\...\Client.csproj]
C:\src\...\.Client.csproj(15,5): error MSB3073: The command "dotnet "C:\Users\...\.nuget\packages\nswag.msbuild\13.15.10\build\../tools/Net60/dotnet-nswag.dll" run nswag.json /variables:Configuration=Debug" exited with code -1.
I did find a workaround - it gets me past the problem.
In the nswag.json file, it fails when I reference the project in the project element of
"documentGenerator": {
"aspNetCoreToOpenApi": {
"project" "../relative/path/to/.csproj",
"assemblyPaths": [
"../../bin/dotnet6.0/MyAPI.dll"
]
}
}
So remove project.
And reference the output DLL from your project in the assemblyPaths[] array.
It builds successfully & the client is regenerated.
After install the App from Microsoft Store it doesn't start and no error message. In "Windows EventHandler - Windows logs - Program" I'm getting this error:
Description: A .NET Core application failed.
Application: MyApp.UI.exe
Path: C:\Program Files\WindowsApps\MyCompany.MyApp_1.0.30.0_neutral__xxxxxxxxxxxxx\MyApp.UI\MyApp.UI.exe
Message: Error:
An assembly specified in the application dependencies manifest (MyApp.UI.deps.json) was not found:
package: 'Microsoft.EntityFrameworkCore.Design', version: '3.1.2'
path: 'lib/netstandard2.0/Microsoft.EntityFrameworkCore.Design.dll'
I don't even reference EntityFrameworkCore.Design.
The App works just fine if Published to folder.
What I have tried:
Removed all Package References and added them back again.
Deploy with references for Microsoft.EntityFrameworkCore.Design even though I should not need need it.
Added and removed Microsoft.EntityFrameworkCore.Design in "Manage NuGet Packages".
Removed and re-added references between Projects.
dotnet restore.
Uninstalled and re-installed Visual Studio 2019 (For some other reasons too, xaml designer was not working)).
Un-loaded Projects and Loaded them back again.
Clean Solution - Deleted obj and bin folders - Clean Solution and Rebuild.
MyApp.UI
MyApp.DataAccess
I would have added .csproj files if I knew how to get formatted properly here...
Have another App in the Microsoft Store with basically the same everything but it works to install and run. The only difference I come across is that it is migrated from .net framework to .net core and uses SQLite instead of SQL server.
Here is parts of MyApp.UI.deps.json that mentions Microsoft.EntityFrameworkCore.Design in "...\MyApp.UI\bin\Release\netcoreapp3.1\publish":
"Microsoft.EntityFrameworkCore.Analyzers/3.1.2": {},
"Microsoft.EntityFrameworkCore.Design/3.1.2": {
"dependencies": {
"Microsoft.CSharp": "4.7.0",
"Microsoft.EntityFrameworkCore.Relational": "3.1.2"
}
},
"Microsoft.EntityFrameworkCore.Tools/3.1.2": {
"dependencies": {
"Microsoft.EntityFrameworkCore.Design": "3.1.2"
}
},
"Microsoft.EntityFrameworkCore.Design/3.1.2": {
"type": "package",
"serviceable": true,
"sha512": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"path": "microsoft.entityframeworkcore.design/3.1.2",
"hashPath": "microsoft.entityframeworkcore.design.3.1.2.nupkg.sha512"
},
So it's obviously something that is being added and should be added. It looks just like the app that works. But what goes wrong when creating the app package or uploading it to the Store?
How is MyApp.UI.deps.json created?
I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:
dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].
My project.json looks like this:
{
"buildOptions": {
"warningsAsErrors": true
},
"dependencies": {
"Microsoft.AspNetCore.Razor": "1.0.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"description": "Precompiles Razor views.",
"frameworks": {
"netcoreapp1.0": {
"imports": [ ]
}
},
"version": "1.2.0"
}
What is hostpolicy.dll, and why is it missing?
Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.
It contains:
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
then dotnet.exe exec "path/to/appname.dll" [appargs] works.
This error message is unhelpful. The actual problem is a missing emitEntryPoint property:
"buildOptions": {
...
"emitEntryPoint": true
},
Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.
If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..
There is a Github issue for this and a workaround.
Edit: Should be fixed in .NET SDK 5.0.200.
I had similar problem running tests in VS19.
========== Starting test run ==========
Testhost process exited with error: A fatal error was encountered. The
library 'hostpolicy.dll' required to execute the application was not
found in 'C:\Program Files\dotnet'. Failed to run as a self-contained
app.
After digging into it I found the source of the problem:
The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.
This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).
Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.
I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.
I am having this problem in Dotnet Core 3.1 Console application.
If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.
If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)
I had this happen with .NET 6.0 where somehow the appname.runtimeconfig.dev.json file was not being generated in the bin/Debug/net6.0/ directory.
The fix was modifying the .csproj file and include this fragment inside the <PropertyGroup> element:
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
I found this solution while searching with https://www.google.com/search?q=net60+runtimeconfig.dev.json at Breaking change: runtimeconfig.dev.json file not generated - .NET | Microsoft Learn with the solution at MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn:
GenerateRuntimeConfigDevFile
Starting with the .NET 6 SDK, the [Appname].runtimesettings.dev.json file is no longer generated by default at compile time. If you still want this file to be generated, set the GenerateRuntimeConfigDevFile property to true.
<PropertyGroup>
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
</PropertyGroup>
After applying this to the .csproj file and re-building the project, debugging from Visual Studio Code worked fine including stopping at the breakpoints that I had set previously.
For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.
Once I modified the version in my .json file the application started working fine.
In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.
The failing package was built using:
dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app
Changing the RID:
dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app
produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 😅
Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...
My problem was that I have 2 .NET Core App projects and one is dependent on the other.
(so I can then execute that application from that other application)
But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.
The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:
COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y
But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.
Note that there should be a better more generic way to do this for every .NET Core App Project automatically.
This error is quite generic. So the real problem can be anything.
In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.
A Class Library DLL can't be runned with MSBuild, even if it has a Main method.
Only Console Application DDL can be runned as dotnet <appname>.dll
I was getting similar error while running Unit tests using VSTest#2 task in Azure Devops.
In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.
Below one worked for me.(if you are getting this error with VSTest)
- task: VSTest#2
displayName: 'Running UnitTests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
$(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
$(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
!**\*TestAdapter.dll
!**\obj\**
platform: x64
configuration: Debug
codeCoverageEnabled: true
So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.
I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.
I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.
I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.
(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)
Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)
For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.
For me, the error occurred during the SonarQube coverage scan due to one of the projects had a project reference to a MSTest project.
I faced this problem and it took me couple of days to figure out the solution.
Go to Visual Studio Installer.
Click on 'More' option of the Visual Studio.
Select 'Repair'.
It'll take some time for the download and installation.
Once it's completed restart the machine and try again.
This should solve the issue.
Add the OutputType on the PropertyGroup and issue is solved
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
more about this MSBuild can be found here
(VS2015 Update 3 + Patch)
I have a plain .NET console application (.NET 4.6) and reference a .NET core class library that targets NetStandard v1.3.
The class library has a reference to Newtonsoft.JSON.
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.6.0",
"Newtonsoft.Json": "9.0.1"
},
"buildOptions": { "platform": "anycpu" },
"frameworks": {
"netstandard1.3": {
"imports": "dnxcore50"
}
}
}
The referenced NewtonSoft.JSON package is deployed here:
C:\Users\UserAccount\.nuget\packages\Newtonsoft.Json\9.0.1
The Exception:
An unhandled exception of type 'System.IO.FileNotFoundException'
occurred in DotNetConsoleApplication.exe
Additional information: Could not load file or assembly
'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral,
PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The
system cannot find the file specified.
I guess the .net core lib would reference the dll from the netstandard1.0 folder.
Creation of NuGet package is a solution but not the easiest one.
Microsoft finally admitted this is a problem and will fix it, expectantly, in NuGet version 4.0.1, the first update to NuGet 4 after VS 2017 ships.
The cleanest workaround now is to add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> to a legacy project. However according to Rob Relyea MS will ignore this property after RTM so another workaround is <PackageReference Update="PlaceholderToConvinceThisProjectToGetTransitivePackageReferenceFromProjectReferences"/>.
Solved 31.07.2016
Create a fresh plain .NET console app (not .NET Core) and a .NET Core class library, without doing any referencing between them upfront.
Scenario:
1. Console app based on .NET 4.6, which references a
2. .Net Core Classlibrary (has a reference to Newtonsoft.JSON v9.01)
The .NET core class library is configured as follows (project.json):
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.6.0",
"Newtonsoft.Json": "9.0.1"
},
"buildOptions": { "platform": "anycpu" },
"frameworks": {
"netstandard1.3": {
"imports": "dnxcore50"
}
}
}
Solution
1.) Create a Nuget package from the .Net core class library project first.
Open the command line as admin.
Go (cd) to the project folder of the .NET core class library project (.xproj).
Run the following command:
dotnet pack
The "pack" parameter will create a nuget package out of the .NET Core class library and copy the package to the debug/release folder, depends on your project configuration.
Copy the nuget package files to a folder where you host your local nuget packages.
I have copied them to:
C:\Users\Admin.nuget\packages\LocalPackages\NetCore46ClassLibrary
Screenshot:
2.) If you don't have a local Nuget feed,you have to create one first!
The local Nuget folder (I named it "LocalPackages") will host your custom Nuget packages. The local Nuget Feed will point to "LocalPackages", which is the root folder for all local packages.
After you have created the local nuget feed and copied the nuget package of your .net core class library somewhere beneath the localPackages folder, you are ready to install your .net core class library nuget package.
3.) Install the .NET Core library Nuget Package into the .NET console app
you now have to open the Package Manager Console again.
Choose Package Source: Local Packages (This is my local feed name, may be different).
And the default project should be your .NET console app.
Install your .net core class library nuget package into the console app, in my case:
install-package NetCore46ClassLibrary
That's it !
My system:
dotnet --version
1.0.0-preview2-003121
Could be that the Newtonsoft assembly is 64 bit and your .Net Core project is 32 bit. Also could be that you have multiple versions of Newtonsoft referenced.
I had the same error recently, after including Newtonsoft.Json 6.0.8 in a dotnet core console app. The solution was to include the System.Runtime.Serialization.Primitives dependancy to the project.json config.
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.0.10-*",
"Newtonsoft.Json": "6.0.8"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"imports": "dnxcore50"
}
}
}
As a workaround solution, In visual studio 2017, you can modify the the NetStandard project .csproj as multi-target:
<TargetFrameworks>netstandard1.3;net461</TargetFrameworks>
Rebuild the solution and the referenced dll (NewtonSoft.JSON) will be copied to bin folder of the console project.
Have a look to my implementation in :Workaround Solution
I'm trying to sign a .net core lib, and I'm just not sure if I did everything correctly
1) using VS Command Promp I called sn -k mykey.snk
2) copied mykey.snk to myproject folder
3) in project.json added keyfile
"frameworks": {
"netstandard1.6": {}
},
"buildOptions": {
"outputName": "MyLib",
"keyFile": "mykey.snk"
}
is this correct, is the library (dll) going to be usable on both .net core and full .net 4.6 apps ?
Yes, this is the correct way. If you look into any ASP.NET Core projects, like Logging, you will find
"buildOptions": {
"keyFile": "../../tools/Key.snk"
...
}
in project.json file, and Key.snk in Tools folder. You also may check .NET Core - strong name assemblies issue.