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 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 installed .NET Core RC2 on a Debian 8 amd64 system and would like to test if it's possible to query an instance of Microsoft SQL Server.
So I'd like to add to my project a dependency on the System.Data.SqlClient assembly.
Presently my project file created by running the dotnet new CLI tool looks like this:
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0-rc2-3002702"
}
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
Using this answer to a similar query, I was able to add a reference to System.Data.Common changing the
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
fragment to
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50",
"dependencies": {
"System.Data.Common": "*"
}
}
}
which made dotnet restore use NuGet to download a bunch of stuff.
I then tried to change that fragment to read
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50",
"dependencies": {
"System.Data.SqlClient": "*"
}
}
}
but NuGet says it's
Unable to resolve 'System.Data.SqlClient' for '.NETCoreApp,Version=v1.0'.
If I change the version string to read "4.1.0-rc3-*" the error message just gets more specific:
Unable to resolve 'System.Data.SqlClient (>= 4.1.0-rc3)' for '.NETCoreApp,Version=v1.0'.
What I'm puzzled about is that the NuGet package gallery dedicated to .NET Core explicitly lists System.Data.SqlClient as available.
So what could I do to add a reference to System.Data.SqlClient assembly to my project and have NuGet download it?
On a side note, I'm currently playing around in a plain console with only the dotnet CLI tool. Is there any way to manage project dependencies for a .NET Core project without resorting to installing IDEs?
Like poke already annotated in the comment is correct. Specify a version to System.Data.SqlClient makes your restore happy ;)
Why is that? System.Data.SqlClient exists in the http://nuget.org gallery. Not specifying a version ("") is not allowed outside of the boundaries of a project (like a nuget feed package) and specifying solely an star "*" (you should never do that, it allows breaking changes) restore the highest available version. Since there is no stable, star will not find anything (there is some magic with the dashes behind). The RC2 version of that library is the mentioned 4.1.0-rc2-24027 and when you ask with 4.1.0-rc2-* it will take the highest of the RC2 builds (but there is only one). In comparison System.Data.Common has a public release on nuget.org for the Universal Windows Platform and is found for that reason.
The RC3 is the next release and only available on developer feeds from the .NET Core and ASP.NET Core team and not the public nuget feed. You should not play with them.
if you are in project.json file, the intellisense guide you now if you have updated the Visual studio with the latest tooling avaiable..
I added the following in the dependencies element and it works perfectly..
"System.Data.SqlClient": "4.1.0-rc2-24027",
On my MINT 19 Tara I do not use System.Data.SqlClient but the newer version Microsoft.Data.SqlClient.
Check nuget
After typing the .NET-cli command, the package was downloaded and the reference was added to the project csproj file.
In the code, use the newer namespace:
using Microsoft.Data.SqlClient;
The "regular" code works fine:
public static void CreateCommand(string queryString, string connectionString)
{
using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlCommand command = new SqlCommand(queryString, connection);
command.Connection.Open();
SqlDataReader reader = command.ExecuteReader() ;
while( reader.Read() ) {
for (int i = 0; i < reader.FieldCount; i++)
{
Console.WriteLine( "Column name={0}, Value={1}",
reader.GetName(i),
reader.GetValue(i) );
}
}
}
}
In the last few days I've been trying out the new .NET CLI and although it's fairly straightforward to build console and web applications it is not being at all obvious how to build a class library.
I did the following: as usual, on the command line I've used dotnet new to create a project.json file. I've then coded a simple class in this project and nothing more.
Then I created a console app with the .NET CLI which included the first one as a dependency on project.json and used the class I've built on the class library to show a message on screen.
When I tried to run the console app, the other project was located and the .NET CLI tried to build it. The build of the class library failed with message:
Program does not contain a static 'Main' method suitable for an entry point.
In that case it was treating the project as a console app and trying to find a main entry point.
I believe this happened because when I created the class library with the dotnet new command it generated the project.json as follows:
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0-*"
}
},
"frameworks": {
"netcoreapp1.0": {}
}
}
Looking there I believe there could be two reasons for this: one of them the fact that the runtime is Microsoft.NETCore.App and second the TFM.
I tried changing the TFM to netstandard1.5 but it didn't work, giving the same error. In that case I believe the issue is with the runtime. Somehow I believe depending on Microsoft.NETCore.App implies we are building a console app and not a library and then one entry point is required.
How is the right way to build a class library with .NET Core CLI then? Is really the runtime the issue? If so, how do we deal with it?
The two issues here are "emitEntryPoint": true and your dependencies section.
A class library will not have an entry point (the static void Main() method) so emitEntryPoint should be set to false.
As for the dependencies, you can either target your required dependencies specifically
"dependencies" : {
"System.Console": "4.0.0-*"
}
or the NETStandard.Library NuGet package
"dependencies" : {
"NETStandard.Library": "1.5.0-*"
}
The NETStandard.Library package is not available from NuGet yet so you'll need to target MyGet until it's officially released. Drop the following into a NuGet.config file within your project folders
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="AspNetCI" value="https://www.myget.org/F/aspnetcirelease/api/v3/index.json" />
<add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
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"
]
}