Related
I have a very basic cli application(that basically prints "hello world") written in C# and that uses the .net core runtime.
I tried to create a chocolatey package by:
running choco new hcli
modifing the generated .nuspec file manually to supply info(version, author...)
running choco pack
This produced a .nupkg file, when I run choco install hcli.0.0.1.nupkg I get ERROR: This package does not support 64 bit architecture.
I am suspecting that chocolatey does not support project.json based projects, the documentation does not mention anything about .net core.
What am I doing wrong?
project.json file:
{
"version": "0.1.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true,
"outputName": "hcli"
},
"dependencies": {},
"frameworks": {
"netcoreapp1.1": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.1.0"
}
},
"imports": "dnxcore50"
}
},
"runtimes": {
"win7-x64": {}
}
}
Chocolatey does not support visual studio projects nor project.json at the time of this post.
Fix the error
What you are seeing is a pretty common error if you have not set up or adjusted any of the packaging.
Have you reviewed the contents of tools\chocolateyInstall.ps1 after you generated the packaging? I would review and adjust those automation scripts that were generated (and review the readme).
If you don't need the automation scripts, simply remove them and have your binaries in the package.
As you have indicated, there is a much more drawn out article at https://chocolatey.org/docs/create-packages
Alternative Option - Use NuGet to pack
You can always look to use NuGet to generate the package and then consume it with Chocolatey. As long as it is compatible with NuGet v2 (currently), you should be good to go. The other aspect of that is that if you have dependencies at the DLL level, please include them in the packaging - dependencies are really at the application level. Like a dependency on dotnetcore package.
I've got 2 projects which are all .NET core. An infrastructure project which defines the schema, models, commands, queries etc. and an API which consists of endpoints/controllers to work on the data. The entire setup resides on Azure with the database being an Azure SQL.
The system is for analytics, so the entire setup is based around Read Only API's and what not. However, I obviously need to insert data into the database. The data comes from software out of my environment, so my idea was to create a WebJob which would receive the payload on an Azure Queue, use NewtonSoft JSON to populate my models and insert it into the database.
If I created a normal Azure WebJob it would use a .NET version which was not compatible with .NET Core, so I instead setup my project as here. In order to set my web job up, i needed to configure it:
public static void Main(string[] args)
{
var config = new JobHostConfiguration
{
DashboardConnectionString = "",
StorageConnectionString = ""
};
var host = new JobHost(config);
// The following code ensures that the WebJob will be running continuously
host.RunAndBlock();
}
In order to use RunAndBlock(); as well as the configuration I need to reference mscorlib, which I do in my project.json:
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.Azure.WebJobs": "1.1.2",
"Microsoft.Azure.WebJobs.Core": "1.1.2",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.3"
},
"Microsoft.NETCore.Portable.Compatibility": "1.0.1",
"Microsoft.WindowsAzure.ConfigurationManager": "3.2.3",
"WindowsAzure.Storage": "8.0.1"
},
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dnxcore50",
"net451"
]
}
},
"publishOptions": {
"include": [
"run.cmd"
]
},
"runtimes": {
"win10-x64": {}
}
}
Reading here regarding the "Microsoft.NETCore.Portable.Compatibility" package, it says:
As such, when using this package you may encounter errors like
error CS0012: The type 'WebRequest' is defined in an assembly that is
not referenced. You must add a reference to assembly
'System.Net.Requests, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'.
Which is exactly what I get,
Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The located assembly's manifest definition does not match the assembly reference.
I am, however, not entirely sure how to fix this. My dependency foo is not super strong, and I'm not sure if I'm even able to get Azure Queue storage + webjobs to play nicely with .NET core
So how do I fix it, if it is fixable?
According to your scenario, I tried to build the NETCore console application for my WebJob and I could encounter the same error as you provided. Then I found some similar issue and issue about WebJob SDK in NETCore, and as David Ebbo stated as follows:
To clarify, Azure WebJobs that use .NET Core work fine. It's specifically the use of the WebJobs SDK that is not yet supported.
Considering your scenario, I assumed that you need to build normal WebJobs and the related library (models,queries,etc.) instead of NETCore, in order to use WebJobs SDK. Or you need to re-design your scenario.
In case somebody is still looking for a solution, this is supported in the recent version
Install-Package Microsoft.Azure.WebJobs -Version 3.0.0-beta4
Please note that this package is still in beta. You can check for the latest updates at https://www.nuget.org/packages/Microsoft.Azure.WebJobs/3.0.0-beta4
(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 have a an ASP.NET Core 1.0 (previously known as ASP.NET 5) solution with a couple of Class Library (Package)'s and an ASP.NET MVC6 project.
I have a test library using the new XUnit 2.0 which supports Core 1.0.
However, for some reason my code coverage is producing zero results when running it on all of my tests which are passing.
By default, ASP.NET Core 1.0 projects are built in-memory by the runtime and no artifacts are persisted to disk. So in the settings I enabled "Produce all outputs on build" for each project in the solution. Now when I build I see the pdb and dll files being output to the artifacts folder. I thought for sure code coverage would work after this, but still no results.
Maybe code coverage just simply doens't work with the new .NET Core 1.0. If anyone has some information on this that would be great.
I'm able to get code coverage with OpenCover 4.6.166 using this configuration :
project.json sample
{
"version": "1.0.0-*",
"dependencies": {
"<project under test>": "1.0.0-*",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"xunit": "2.2.0-beta2-build3300"
},
"frameworks": {
"net451": {
"dependencies": {
"Moq": "4.5.16"
}
},
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"moq.netcore": "4.4.0-beta8",
"System.Diagnostics.Process": "4.1.0",
"System.Diagnostics.TraceSource": "4.0.0"
},
"imports": [
"dnxcore50",
"portable-net451+win8"
]
}
},
"testRunner": "xunit"
}
I use the myget CI feed my NuGet.config :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<!--<add key="aspnetmaster" value="https://www.myget.org/F/aspnetmaster/api/v3/index.json" />-->
<!--<add key="aspnetlatest" value="https://www.myget.org/F/aspnetvnext/api/v2" />-->
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
</packageSources>
</configuration>
Restore dependencies with --infer-runtimes option:
dotnet restore --infer-runtimes
Then use OpenCover with this command line :
OpenCover.exe -target:"C:\Program Files\dotnet\dotnet.exe" -targetargs:" test ""<your project path>\project.json"" -f net451 -xml ""test\ChatLe.Repository.Test\xunit-results.xml"" -nologo -parallel none" -output:"<your coverage .xml path>" -register:user -filter:"+[*]* -[xunit*]* -[*]*Migrations.*" -returntargetcode
Note the -f net451 switch is important, it says to dotnet to use the net451 framework. To cover netcoreapp1.0 use -f netcoreapp1.0.
In my console output, I can see those result :
I got a .NET Core project with working code coverage using xUnit 2.*, Appveyor, OpenCover and Coveralls, but it had to be extended to .NET Platform Standard. You can see the results on the relevant open source library here.
Some notable conclusions:
I couldn't find a way to get OpenCover to pay attention to 'portable' debugType *.pdb files. I had to use the legacy, Windows-only 'full' *.pdb format. This is done by setting 'debugType' to 'full' under 'buildOptions' in your project's 'project.json' file.
I had to run OpenCover on Windows, and it had to run via some version of the traditional .NET Framework. If you haven't yet, configure your non-test project to use .NET Platform Standard instead of .NET Core explicitly, like I did here. Then, in your test project, break apart your .NET Core and your traditional .NET Frameworks, like I did here. Assuming you use .NET Platform Standard 1.6, you would use net463 where I have net46.
Run OpenCover using the traditional .NET Framework via the dotnet test command line tool, not the xUnit console runner. You can see my code coverage generation (and submission) powershell script here. Where I specify net46, you would specify the version you used in your test project (presumably net463).
Here's the script pulled from source. You may or may not need to adjust the filter argument with respect to your dependencies.
nuget install OpenCover -Version 4.6.519 -OutputDirectory tools
nuget install coveralls.net -Version 0.7.0 -OutputDirectory tools
.\tools\OpenCover.4.6.519\tools\OpenCover.Console.exe -target:"C:\Program Files\dotnet\dotnet.exe" -targetargs:" test ""test\Invio.Extensions.DependencyInjection.Tests\project.json"" -f net46" -register:user -filter:"+[*]* -[xunit*]*" -returntargetcode -output:opencover_results.xml
.\tools\coveralls.net.0.7.0\tools\csmacnz.Coveralls.exe --opencover -i .\opencover_results.xml
Technically, this isn't testing .NET Core. This is testing the traditional .NET Framework's interpretation of an otherwise .NET Core project. However, if you do not do any conditional compilation based upon which framework you're using, the code coverage results will be identical.
A minor word of caution: if you look at the example repository, you'll see that I have a debugType of portable, not full, for my project.json file. That's because I am using Travis CI for Linux & Mac OS X builds, and that fails when you use full debugTypes. I got around this by setting mine programmatically via a powershell script running after my build on appveyor.
I've got it working XUnit.
Important things to note:
xunit.runner.json is where your xunit configurations go
Microsoft.CodeCoverage package is needed to run code coverage in visual studio
You will get all tests shown in the Test Runner Explorer. You can also analyze code coverage with the Visual Studio menu item. Only thing I haven't got working is code coverage highlighting: code coverage highlighting in .net core visual studio
This is my project.json
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"copyToOutput": {
"include": [ "xunit.runner.json" ]
}
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.1.1",
"xunit": "2.1.0",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"ClanService": { "target": "project" },
"Utilities": { "target": "project" },
"UnitTests.Configuration": { "target": "project" },
"Microsoft.CodeCoverage": "1.0.2"
},
"testRunner": "xunit",
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"imports": [
"dotnet5.4",
"portable-net451+win8"
]
}
}
}
I followed this blog and was able to get some results, with opencover, althought I don't think it's correct.
And I need to investigate why the wrong numbers, if you find/found a way to do it, please share.
http://dotnetthoughts.net/measuring-code-coverage-of-aspnet-core-applications-using-opencover/
There is a thread in the OpenCover GitHub repository about this topic. The trick to making it work is noted in a wiki post.
The trick (user supplied) is to use the --lib argument of dnx.exe e.g.
OpenCover.Console.exe -target:"C:\<path-to-dnx>\dnx-clr-win-x86.1.0.0-beta6\bin\dnx.exe"
"-targetargs:--lib c:\projects\<path-to-site>\website\bin\debug\dnx451 --lib
c:\projects\\common\bin\debug\dnx451 -p
c:\projects\\test\Website.Tests test"
-output:coverage.xml
-filter:+[Website]*
I'm trying to run a modified version of the HelloWeb sample for ASP.NET vNext on DNX using Kestrel. I understand that this is very much on the bleeding edge, but I would hope that the ASP.NET team would at least keep the simplest possible web app working :)
Environment:
Linux (Ubuntu, pretty much)
Mono 3.12.1
DNX 1.0.0-beta4-11257 (I have 11249 available too)
"Web app" code, in Startup.cs:
using Microsoft.AspNet.Builder;
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.UseWelcomePage();
}
}
Project config, in project.json:
{
"dependencies": {
"Kestrel": "1.0.0-beta4",
"Microsoft.AspNet.Diagnostics": "1.0.0-beta4",
"Microsoft.AspNet.Hosting": "1.0.0-beta4",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta4",
"Microsoft.AspNet.StaticFiles": "1.0.0-beta4",
"Microsoft.Framework.Runtime": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Common": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Loader": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Interfaces": "1.0.0-beta4",
},
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnx451": {}
}
}
kpm restore appears to work fine.
When I try to run, however, I get an exception suggesting that Microsoft.Framework.Runtime.IApplicationEnvironment can't be found. Command line and error (somewhat reformatted)
.../HelloWeb$ dnx . kestrel
System.IO.FileNotFoundException: Could not load file or assembly
'Microsoft.Framework.Runtime.IApplicationEnvironment,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'Microsoft.Framework.Runtime.IApplicationEnvironment,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke
(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke
(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x00000] in <filename unknown>:0
While obviously, my most pressing need is to fix this, I'd also appreciate advice on how to move to diagnose what's going wrong so I can fix similar issues myself in the future. (That's also likely to make this question more useful to others, too.)
I've found Microsoft.Framework.Runtime.IApplicationEnvironment in the Microsoft.Framework.Runtime.Interfaces assembly source, and that doesn't appear to have changed recently. It's not clear why the exception shows the name as if it's a whole assembly in itself, rather than just an interface within another assembly. I'm guessing this may be due to assembly neutral interfaces, but it's not clear from the error. ([AssemblyNeutral] is dead, so that's not it...)
Good question. For your specific problem, it looks like you have a mismatch in your resolved dependencies. When things like this happen it's likely because you're running your application on an incompatible dnx. We're still making very big breaking changes so if you ever see method missing of type missing, chances are you ended up running betaX packages and betaY dnx or vice versa.
Even more specifically, Assembly Neutral Interfaces were removed in beta4 but it looks like the application you are running is still using them.
We have plans to make it so that packages can mark the minimum dnx that they require to run to make the error message more clear. Also as time goes by, the breaking changes will die down.
In general though, I feel like it's time I wrote a guide on how to diagnose issues like this when using the dnx (since it's pretty different to existing .NET).
Dependencies you put into project.json are top level only. Versions are also always minimums (it's just like a NuGet package). This means that when you specify Foo 1.0.0-beta4 you're really specifying Foo >= 1.0.0-beta4. This means if you ask for MVC 0.0.1 and the minimum versions on your configured feed is MVC 3.0.0, you'll get that one. We also NEVER float your version unless you specify it. If you ask for 1.0.0 and it exists, you will get 1.0.0 even if newer versions exist. Specifying empty versions is ALWAYS bad and will be disallowed in later builds.
There's a new feature we're introducing to nuget called floating versions. Today it only works on the prerelease tag, but in the next version it'll work on more parts of the version. This is similar to npm and gem syntax for specifying version ranges in the package specification file.
1.0.0-* - Means give me the HIGHEST version matching the prefix (according to semantic versioning rules) OR if there is no version matching that prefix, use normal behavior and get me the LOWEST version >= the specified version.
When you run restore in the latest builds, it will write out a file called project.lock.json. This file will have the transitive closure of dependencies for all target frameworks defined in project.json.
When something like this fails you can do the following:
Take a look at the resolved dependencies using kpm list. This will show you the resolved versions of packages referenced by your project and what dependency pulled it in. e.g. if A -> B, it'll show:
A
-> B
B
->
Actual KPM list output:
Listing dependencies for ClassLibrary39 (C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json)
[Target framework DNX,Version=v4.5.1 (dnx451)]
framework/Microsoft.CSharp 4.0.0.0
-> ClassLibrary39 1.0.0
framework/mscorlib 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System.Core 4.0.0.0
-> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
[Target framework DNXCore,Version=v5.0 (dnxcore50)]
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
System.Runtime 4.0.20-beta-22709
-> ClassLibrary39 1.0.0
* means direct dependency.
If you have a working visual studio (which breaks with DNX right now), you can look at the references node. It has the same data represented visually:
Let's look at what a dependency failure looks like:
Here's the project.json
{
"version": "1.0.0-*",
"dependencies": {
"Newtonsoft.Json": "8.0.0"
},
"frameworks" : {
"dnx451" : {
"dependencies": {
}
},
"dnxcore50" : {
"dependencies": {
"System.Runtime": "4.0.20-beta-22709"
}
}
}
}
Newtonsoft.Json 8.0.0 doesn't exist. So running kpm restore shows the following:
When diagnosing when restore might have failed, look at the HTTP requests made, they tell you what configured package sources kpm looked in. Notice in the above image, there is a CACHE request. This is the built in caching based on the type of resource (nupkg or nuspec) and has a configurable TTL (look at kpm restore --help). If you want to force kpm to hit the remote NuGet sources, use the --no-cache flag:
These errors also show up in Visual Studio in the package manager log output window:
Side note!
Package Sources
I'll describe the way NuGet.config works right now (which will likely change in the future). By default you have a NuGet.config with the default NuGet.org source configured globally in %appdata%\NuGet\NuGet.Config. You can manage these global sources within visual studio or with the NuGet command line tool. You should always look at your effective sources (the ones listed in the kpm output) when trying to diagnose failures.
Read more about NuGet.config here
Back to reality:
When dependencies are unresolved, running the application will give you this:
> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
Newtonsoft.Json 8.0.0
Searched Locations:
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll
Try running 'kpm restore'.
at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)
The runtime basically tries to validate that the entire dependency graph is resolved before attempting to run. If it suggests running kpm restore it's because it can't find the dependencies listed.
Another reason why you might get this error is if you're running the wrong dnx flavor. If your application only specifies dnx451 and you try to run the CoreCLR dnx, you might see a similar problem. Pay close attention to the target framework in the error message:
For running:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
When you're trying to run, you should remember that mental mapping from clr to target framework defined in your project.json.
This also shows up in Visual Studio under the references node:
The nodes marked as yellow are unresolved.
These also show up in the error list:
Building
These errors also show up when building. When building from the command line, the output is very verbose and can be extremely useful when diagnosing problems:
> kpm build
Building ClassLibrary39 for DNX,Version=v4.5.1
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Assembly dependency framework/mscorlib 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll
Using Assembly dependency framework/System 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll
Using Assembly dependency framework/System.Core 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll
Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll
Building ClassLibrary39 for DNXCore,Version=v5.0
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Package dependency System.Console 4.0.0-beta-22709
Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
File: lib\contract\System.Console.dll
Using Package dependency System.IO 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
File: lib\contract\System.IO.dll
Using Package dependency System.Runtime 4.0.20-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
File: lib\contract\System.Runtime.dll
Using Package dependency System.Text.Encoding 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
File: lib\contract\System.Text.Encoding.dll
Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
File: lib\contract\System.Threading.Tasks.dll
The output shows all of the assemblies passed into the compiler from packages and project references. When you start getting build failures, it's useful to look here to make sure that the package you are using actually works on that target platform.
Here's an example of a package that doesn't work on dnxcore50:
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.Owin.Host.SystemWeb": "3.0.0"
},
"frameworks": {
"dnx451": {
"dependencies": {
}
},
"dnxcore50": {
"dependencies": {
"System.Console": "4.0.0-beta-22709"
}
}
}
}
Microsoft.Owin.Host.SystemWeb version 3.0.0 does not have any assemblies that run on dnxcore50 (take a look at the unzipped package's lib folder). When we run kpm build:
Notice it says "using Package Microsoft.Owin.Host.SystemWeb" but there is not "File:". This could be the reason for a build failure.
Here ends my brain dump
I still don't know entirely what was wrong, but I now have a series of steps to at least make it easier to try things:
When in doubt, reinstall dnx
Blowing away the package cache can be helpful
Check ~/.config/NuGet.config to ensure you're using the right NuGet feeds
I ended up using the following command line to test various options in a reasonably clean way:
rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel
It looks like my problem was really due to the wrong versions of the dependencies being installed. A version number of "1.0.0-beta4" is apparently quite different to "1.0.0-beta4-*". For example, the Kestrel dependency installed version 1.0.0-beta4-11185 when just specified as 1.0.0-beta4, but version 1.0.0-beta4-11262 with the -* at the end. I wanted to specify beta4 explicitly to avoid accidentally using a beta3 build with the
The following project config works fine:
{
"dependencies": {
"Kestrel": "1.0.0-beta4-*",
"Microsoft.AspNet.Diagnostics": "1.0.0-beta4-*",
"Microsoft.AspNet.Hosting": "1.0.0-beta4-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta4-*",
},
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnx451": {}
}
}
You can set an env var named DNX_TRACE to 1 to see a TON more diagnostic info. Be warned, it's a lot more info!
To get it to work I modified my project.json .. it now looks like:
{
"dependencies": {
"Kestrel": "1.0.0-*",
"Microsoft.AspNet.Diagnostics": "1.0.0-*",
"Microsoft.AspNet.Hosting": "1.0.0-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-*",
"Microsoft.AspNet.StaticFiles": "1.0.0-*"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5001",
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
}
}
The key seemed to be the frameworks section.
Also the rename changed how k web works so that its now dnx . web or dnx . kestrel
Update - bit more info
Oddly, after running with no frameworks defined it went and got a bunch of extra stuff when I did kpm restore :
...
Installing Microsoft.Framework.Logging 1.0.0-beta4-11001
Installing Microsoft.Framework.Logging.Interfaces 1.0.0-beta4-11001
Installing Microsoft.Framework.DependencyInjection.Interfaces 1.0.0-beta4-11010
Installing Microsoft.Framework.DependencyInjection 1.0.0-beta4-11010
Installing Microsoft.Framework.ConfigurationModel 1.0.0-beta4-10976
Installing Microsoft.Framework.ConfigurationModel.Interfaces 1.0.0-beta4-10976
Installing Microsoft.AspNet.Hosting.Interfaces 1.0.0-beta4-11328
Installing Microsoft.AspNet.FeatureModel 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http 1.0.0-beta4-11104
Installing Microsoft.AspNet.FileProviders.Interfaces 1.0.0-beta4-11006
Installing Microsoft.Framework.Caching.Interfaces 1.0.0-beta4-10981
Installing Microsoft.AspNet.FileProviders 1.0.0-beta4-11006
Installing Microsoft.AspNet.Http.Core 1.0.0-beta4-11104
Installing Microsoft.AspNet.WebUtilities 1.0.0-beta4-11104
Installing Microsoft.Net.Http.Headers 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http.Interfaces 1.0.0-beta4-11104
Installing Microsoft.Framework.Runtime.Interfaces 1.0.0-beta4-11257
Installing Microsoft.AspNet.Server.Kestrel 1.0.0-beta4-11262
Installing Microsoft.Net.Http.Server 1.0.0-beta4-11698
Installing Microsoft.Net.WebSockets 1.0.0-beta4-11698
Installing Microsoft.Net.WebSocketAbstractions 1.0.0-beta4-10915
Installing Microsoft.Framework.WebEncoders 1.0.0-beta4-11104
Installing Microsoft.Framework.OptionsModel 1.0.0-beta4-10984
Installing Microsoft.AspNet.Http.Extensions 1.0.0-beta4-11104
Installing Microsoft.AspNet.Diagnostics.Interfaces 1.0.0-beta4-12451
Installing Microsoft.AspNet.RequestContainer 1.0.0-beta4-11328
.. then it ran fine. Then I switched back in the framework section
"frameworks": {
"dnx451": {}
}
.. and it still worked, whereas before it would throw up an error !
Very odd!
(Im running 1.0.0-beta4-11257)
Further update
I spun up a new Ubuntu instance, and got the same error as you .. My thought was that the issue may be caused by it only trying to get packages from nuget.org and not myget.org (which has the newer things) so i dropped in a NuGet.Config into the root of the project..
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/" />
<add key="NuGet" value="https://nuget.org/api/v2/" />
</packageSources>
</configuration>
.. this seems to have fixed it for me by getting the correct versions (after another kpm restore).
These days, all of my package.json versions end in "-rc2-*"
(Only exceptions I've seen so far are the Microsoft.Framework.Configuration packages, which need to be either "1.0.0-rc1-*" or "1.0.0-*")
Regarding the "version trains" that #davidfowl mentions, it seems a LOT of pain has disappeared between beta8 and rc2.
dnvm upgrade -u -arch x64 -r coreclr
I've had the most luck on coreclr with these 2 NuGet feeds:
"https://www.myget.org/F/aspnetvnext/"
"https://nuget.org/api/v2/"
When I do have missing package problems, 90% of the time it's these same culprits:
Newtonsoft.Json
Ix-Async
Remotion.Linq
Most of the time, I can get around these by forcing the main NuGet.org feed:
dnu restore;
dnu restore -s https://nuget.org/api/v2
Here is my working config.json:
{
"dependencies": {
"Microsoft.AspNet.Diagnostics": "1.0.0-rc2-*",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc2-*",
"Microsoft.AspNet.Hosting": "1.0.0-rc2-*",
"Microsoft.AspNet.Http": "1.0.0-rc2-*",
"Microsoft.AspNet.Http.Abstractions": "1.0.0-rc2-*",
"Microsoft.AspNet.Mvc.Core": "6.0.0-rc2-*",
"Microsoft.AspNet.Mvc.Razor": "6.0.0-rc2-*",
"Microsoft.AspNet.Owin": "1.0.0-rc2-*",
"Microsoft.AspNet.Routing": "1.0.0-rc2-*",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc2-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-rc2-*",
"Microsoft.AspNet.Session": "1.0.0-rc2-*",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc2-*",
"EntityFramework.Commands": "7.0.0-rc2-*",
"EntityFramework.Core": "7.0.0-rc2-*",
"EntityFramework.InMemory": "7.0.0-rc2-*",
"EntityFramework.MicrosoftSqlServer": "7.0.0-rc2-*",
"EntityFramework.MicrosoftSqlServer.Design": "7.0.0-rc2-*",
"EntityFramework.Relational": "7.0.0-rc2-*",
"EntityFramework7.Npgsql": "3.1.0-beta8-2",
"Microsoft.Extensions.Logging.Abstractions": "1.0.0-rc2-*",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-*",
"Microsoft.Extensions.DependencyInjection": "1.0.0-rc2-*",
"Microsoft.Extensions.DependencyInjection.Abstractions": "1.0.0-rc2-*",
"Microsoft.Framework.Configuration.CommandLine": "1.0.0-*",
"Microsoft.Framework.Configuration.EnvironmentVariables": "1.0.0-*",
"Microsoft.Framework.Configuration.Json": "1.0.0-*"
},
"commands": {
"ef": "EntityFramework.Commands",
"dev": "Microsoft.AspNet.Hosting --ASPNET_ENV Development --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnxcore50": {}
}
}
I was having dependency missing issues as well with trying to appease dnxcore50 and dnx451 references.
If I understand this right "dependencies": {} are shared between the frameworks.
Then "dependencies":{} within the "frameworks": are specific to that framework.
dnxcore50 is a modular runtime (self contained) so it basically contains all the core runtimes need to run a program unlike classic .net framework where you have core dependencies scattered about elsewhere.
So with that said I wanted to stick to the minimal approach incase I decided to host on mac or linux at some point.
Update
Ran into weird dependency issues with cshtml views, just went with dnx451 for now.
This is my project.json
{
"webroot": "wwwroot",
"version": "1.0.0-*",
"dependencies": {
"System.Runtime": "4.0.10",
"Microsoft.AspNet.Hosting": "1.0.0-beta4",
"Microsoft.AspNet.Mvc": "6.0.0-beta4",
"Microsoft.AspNet.Server.IIS": "1.0.0-beta6-12075",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta6-12457",
"Microsoft.Framework.DependencyInjection": "1.0.0-beta4",
"Microsoft.Framework.DependencyInjection.Interfaces": "1.0.0-beta5"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://admin.heartlegacylocal.com" },
"frameworks": {
"dnx451": { }
}
},
"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
],
"exclude": [
"wwwroot",
"node_modules",
"bower_components"
]
}