I have a legacy assembly that is still on .NET Framework 4.8 and references System.Windows.Forms.dll (for non-UI reasons, actually) and I would like to use it inside a .NET Interactive Notebook through also existing code that loads this assembly using Assembly.LoadFrom.
However, if I do that, I end up getting an exception Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.. So in my opinion, essentially the runtime is not looking into the .NET 4 GAC, because it is not a .NET 4 CLR and then expecting the assembly to be located in the same folder.
In applications that are under control, we had some good success simply changing the target framework moniker to net6.0-windows in that case, but recompile obviously is not an option for interactive notebooks.
I have seen that there is a runtimeconfig.json in the Nuget cache folder for the entry DLL:
{
"runtimeOptions": {
"tfm": "net6.0",
"frameworks": [
{
"name": "Microsoft.NETCore.App",
"version": "6.0.0"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "6.0.0"
}
],
"configProperties": {
"System.GC.Server": true,
"System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
"System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
}
}
}
However, changing the tfm setting there did not seem to work, either. What am I doing wrong?
I forgot to paste the solution here in case anybody runs into the same problem. I actually just copied the assembly from the GAC into the application folder and then, .NET Core was able to find the assembly.
I'm working on a .net Core project, using the .net Core framework, I wanted to use DropNet package with .net Core so I added a reference to net452 framework inside my project.json:
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8",
"net452"
]
}
},
Now when I try to create a DropNet client object in my controller class I've got an error:
Error CS0012 The type 'IWebProxy' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'. Test3..NETCoreApp,Version=v1.0
Ok in order to fix that error I've installed microsoft.netcore.portable.compatibility package, and the error is gone, the thing is that when I do that and execute the project and try to get access to the View that I'm returning from the controller action where I'm using DropNet I get a FileNotFoundException :
FileNotFoundException: Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
I'm having that problem only with that view, this is my Action Method:
public IActionResult Test()
{
DropNetClient client = new DropNetClient("gsfgsgsfg438", "6ysgsgs234cf", userToken: "w5gdfgsdfg3434d4", userSecret: "239usfgsghsf3434wyqo");
return View();
}
The problem is that DropNetClient line, if a comment that line, the view is showed, but if that line is active in there, the FileNotFoundException is thrown...
Please, don't abuse the import statement. It is there to override nuget validation when restoring packages, to install libraries which are compatible (PCL which target .NET 4.5 and Windows 8/8.1+) but do not yet have the netstandard1.6 target.
Don't EVER use it to force import net452 libraries into a .NET Core application. It won't work!!! .NET 4.5.2 libraries aren't compatible with .NET Core!!!
You only have two options:
Don't use any libraries which do not support netstandard, netcoreapp or portable-net45+win8!!!
If you need some libraries that only run with net452 and there is no replacement, then target net452 instead of netcoreapp1.0
(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
Created a new Class Library (Package) project
Changed the project.json to look like this (added project dependencies):
project.json
{
"version": "1.0.0-*",
"description": "WMI.ECM.PCMS.Services.Acomba Class Library",
"authors": [ "WILL" ],
"tags": [ "" ],
"projectUrl": "",
"licenseUrl": "",
"dependencies": {
"Acomba.SDK": "2.0.0",
"WMI.ECM.Inventory.Models": "",
"WMI.ECM.Inventory.Services": "",
"WMI.ECM.Inventory.Services.Contracts": ""
},
"frameworks": {
"dnx451": { },
"dnxcore50": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Collections": "4.0.11-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading": "4.0.11-beta-23516"
}
}
}
}
Compiled the solution, and I get this error:
The type 'DateTime' is defined in an assembly that is not referenced. You must add a reference to assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PunlicKeyToken=b77a5c561934e089'.
Yet, I do not have this problem with my other projects which also target DNX451 and DNXCORE50. Also shall I mention that the mscorlib.dll is actually referenced in the project in question per this screenshot: Referenced assemblies.
As a result, I did some searches which end up clueless.
I tried to add dependencies to the dnx451{} in my project.json like so:
"dnx451": {
"dependencies": {
"Microsoft.CSharp": "",
"System.Runtime": ""
...
}
}
Because I remember having read such a solution somewhere, and it didn't work.
Most of the answers are for an older version of a web project which solve it by adding a reference in the web.config. Well, Class Library (Package) has no web.config.
The type ‘System.Object’ is defined in an assembly that is not reference (MVC + PCL issue)
CS0012: The type 'System.Web.Routing.RouteValueDictionary' is defined in an assembly that is not referenced
I also downloaded and installed this patch:
Microsoft .NET Framework 4.5.2 Developer Pack, which changed nothing.
And another one which I can barely understand what is discussed because they are talking about the facades for each and every version of the framework or something like it.
The type 'System.Object' is defined in an assembly that is not referenced
It looks like a common problem although I can't find any helpful solution to the actual problem.
Currently using
Visual Studio Community 2015 - Version 14.0.25123.00 Update 2
.NET Framework 4.6.01055
ASP.NET MVC 6 Installed
SideWaffle for Xunit DNX Unit Test Project Template
Visual C# 2015
UPDATE
It appears to be caused by the COM library which I imported using this tool from the VS CMD line: Tlbimp.exe (Type Library Importer).
In short, the AcoSDK.dll is a COM library which I imported using the above-mentioned tool to create a .NET assembly with all the COM types resolved as .NET types.
Then, I used NuGet.exe to create a package which I published over my private feed.
And then, I referenced the package in my project as "Acomba.SDK": "2.0.0" in my project.json.
Whenever I use a DateTime property from this package, the build error occurs. For example, this causes the error to occur:
public DateTime CreatedAt { get { return p.PrTimeModified; } }
And this doesn't:
public DateTime CreatedAt { get { return new DateTime(); } }
The COM type for a .NET DateTime is Date. However, it's supposed to be seen as a DateTime following the steps in the examples provided on the tlbimp.exe command line.
It is only when I added a dot to the property that I saw that the DateTime was not supported in DNXCORE50. Except that it is for native DateTime such as 'new DateTime()' (see screenshot here).
Any clue as to how to workaround this?
As per this issue reported on GitHub: Accessing mscorelib in DNX Core 5.0 #989, it seems that the Core CLR doesn't support well the COM types that refer to mscorlib.dll.
Besides, there's a package available to workaround this issue which is:
Microsoft.NETCore.Portable.Compatibility.
In short, all it does is a remap of the types referencing to mscorlib.dll such as COM objects to the newer releases of System.Runtime and other libraries, which in turn refers to its corresponding DLL for the right version or so.
So the solution is to add this package in the project.json as follows:
project.json
"frameworks": {
"dnx451": { },
"dnxcore50": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"Microsoft.NETCore.Portable.Compatibility": "1.0.1-beta-23516",
"System.Collections": "4.0.11-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading" : "4.0.11-beta-23516"
}
}
}
For greater details about this package, and to know more about the issue, I strongly suggest to follow the links provided as they cover a more in-depth information.
In the end, it solved the problem! =)
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"
]
}