I am migrating a .Net Framework library to .Net standard and the compiler cannot find the core builders from System.Reflection.Emit.
If I am in the right place then the API documentation states that these builders (MethodBuilder, ModuleBuilder and AssemblyBuilder) are part of System.Reflection.Emit.
This is the project.json for my library:
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable"
},
"dependencies": {},
"frameworks": {
"netstandard1.6": {
"dependencies": {
"NETStandard.Library": "1.6.0"
}
}
}
}
Do I need any additional reference?
You can find them in "System.Reflection.Emit": "4.3.0" nugget package for the netstandard1.6 framework.
The "animalito maquina" answer also worked for me but I have investigated the problem a little bit using netstandard2.0. It might not be relevant to this question but I wanted to share this with you since it still might help others :).
I generated two projects(dotnet new):
"classlib" which uses netstandard2.0 on default
...and "console" which uses the netcoreapp2.0
I added references to AssemblyBuilder class in both projects. The AssemblyBuilder was missing in "classlib" project that has been using netstandard2.0 but was available in "console" project - netcoreapp2.0.
The "problem" is caused by the fact that .NET Core Libraries are actually always a superset of the APIs defined in the corresponding version of the .NET Standard. There are always types and members available in the .NET Core Libraries, which are not (yet?) part of the .NET Standard.
These links might be helpful:
https://github.com/dotnet/standard/tree/master/docs/comparisons
Advantages of netcoreapp2.0 vs netstandard2.0 for a library project
https://github.com/dotnet/standard/blob/master/docs/comparisons/netstandard2.0_vs_netcoreapp2.0/README.md
https://github.com/dotnet/cli/issues/7335
I have a .Net Core Class Library which can be nicely referenced successfully from a .Net Core Console App.
I am trying to reference the class library from a .Net 4.6.2 console app now, and it seems to reference ok, but when I try to instantiate an object from the .Net Core Lib, it can't find it. Oddly enough if I try to add a reference to the DLL directly using the /bin/Debug folder of the .Net Core Class Lib it works...
It also works if I package it up as a nuget package and add it that way. My .Net Core Class Library's project.json is below. You can see the whole solution in ObjectHydrator at https://github.com/PrintsCharming/ObjectHydrator/tree/v2-alpha-1
{
"version": "2.0.0-*",
"dependencies": {
},
"frameworks": {
"net46": {
"dependencies": {
},
"frameworkAssemblies": {
"System.ComponentModel.DataAnnotations": "4.0.0.0"
}
},
"netcoreapp": {
"dependencies": { "System.ComponentModel.Annotations": "4.1.0" },
"imports": "dnxcore50"
}
}
}
Right now it is possible to add dependency to .Net Core Class Library only via Nuget. This is cause the new project templates/.xproj works a bit differently.
Assembly references should be supported directly again with the move to use csproj projects for .NET Core (referencing third party dll's issue)
I am trying to migrate an Asp.Net Core RC1 project to RC2 and have been following this documentation and have also followed the instructions for DNX migration to .NET CLI.
I am getting the following error when I try dotnet run:
Can not find runtime target for framework '.NETCoreAPP, Version=v1.0'
compatible with one of the target runtimes: 'win10-x64, win81-x64,
win8-x64, win7-x64'. Possible causes:
The project has not been restored or restore failed -run 'dotnet restore'
The project does not list one of 'win10-x64, win81-x64, win7-x64' in the 'runtimes'
I have run dotnet restore and it seems to have completed successfully.
I have updated all the relevant packages to RC2.
I should have done exactly what the error message said. When migrating from RC1, I did not realise that I had to specify a runtimes section in my project.json file.
In my project.json I added the following section:
"runtimes": {
"win10-x64": { }
}
And I was good to go.
Update 27 February 2017
New project templates in Visual Studio 2017 RC no longer require run times to be specified (in project.json or .csproj) in advance if you choose to deploy your app as a Framework Dependent Deployment (FDD).
If, however, you choose to deploy your app using Self-contained Deployment (SCD), then you will need to specify all the run times you want your app to run on in advance in your .csproj file.
Below is an example of a .csproj file for an app that uses the SCD deployment method:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<VersionPrefix>1.0.0</VersionPrefix>
<DebugType>Portable</DebugType>
<RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
</ItemGroup>
</Project>
Please see this link for more information, which includes a thorough description of both types of deployment options, as well as their benefits and disadvantages.
I received this error after updating VS2015 core template to 1.0.1. It was because I have a PCL that targets netstandard 1.4 if you don't want to have to specify each runtime, Just change the dependency markup for Microsoft.NETCore.App to this:
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
in project.json I changed this (added type):
//"Microsoft.NETCore.App": "1.1.0",
"Microsoft.NETCore.App": { "version": "1.1.0", "type": "platform" },
Now I can build again :-)
update: now I can build again but not "run" the website.
You need to make sure you have the runtime and sdk also:
*) Visual Studio tools include .NET Core 1.0.1. To add .NET Core 1.1 support you need to also install the .NET Core 1.1 runtime.
https://www.microsoft.com/net/download/core#/current
I received this error because I used the incredibly broken NuGet Package Manager in Visual Studio 2015 to update my project.json dependencies. It turned this:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
}
}
}
into this:
"dependencies": {
"Microsoft.NETCore.App": "1.1.0"
},
"frameworks": {
"netcoreapp1.0": {}
}
Bye bye, platform definition!
If you read these two links:
First, https://learn.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli
and
second, https://learn.microsoft.com/en-us/dotnet/articles/core/rid-catalog
You will see that you can build a completely portable version using the following snippet in the dependencies root element in project.json. There is no need to specify runtimes as this is a CORE level runtime which should be platform agnostic, or known as "Framework dependent"
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
or you can build for multiple targeted platforms ("self contained applications") by removing the type: platform element like this:
Add this to the dependencies root element in project.json
"Microsoft.NETCore.App": {
"version": "1.0.1"
}
and add this as a new root level element
"runtimes": {
"win10-x64": {}, /* one or more RIDs */
"osx.10.10-x64": {}
},
Multiple targeted requires that you supply platform names known as ".NET Core Runtime IDentifiers (RID)" A list of these can be found at the second link above. It includes many flavors of Windows, Linux and OS X.
For a good overview of the various deployment optins, you can read this page as well:
https://learn.microsoft.com/en-us/dotnet/articles/core/deploying/index
From the above link:
You can create two types of deployments for .NET Core applications:
Framework-dependent deployment
As the name implies, framework-dependent deployment (FDD) relies on a shared system-wide version of .NET Core to be present on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example, dotnet app.dll runs an application named app.
Self-contained deployment
Unlike FDD, a self-contained deployment (SCD) does not rely on any shared components to be present on the target system. All components, including both .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.
In my case I had just updated all the nuget packages to their latest versions and nuget changed my 'Microsoft.NETCore.App' package reference to the following:
"Microsoft.NETCore.App": "1.1.0"
I changed it back to the following form and everything worked fine:
"Microsoft.NETCore.App": {
"version": "1.1.0",
"type": "platform"
}
Good bye 3 hours of my life....
if you execute a dotnet new and look at the output project json, you will see that the monikers have changed.
Make the changes to your project.json as follows:
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"imports": "dnxcore50"
}
}
I found one useful link from comment by svick under following page:
https://github.com/dotnet/cli/issues/2442
I found you need the following in project.json. Here is what was required to fix my error:
Dependencies
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
}
Frameworks
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
},
Runtime
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},
You might want to add runtimes if you plan on publishing to IIS. Please see something as follows:
"runtimes": {
"win10-x64": {}
},
Here is a general tip that has worked well for me. When my stuff breaks, I sometimes create a default ASP.NET Core application either the website or empty web api to look at the dependencies in project.json and elsewhere. You can often catch a lot of things that way. The answers above are spot on, but I thought I would write this here in case someone wanted to separate the logic out more in the general template format that ASP.NET Core uses.
In Windows 7 with VS 2015, the soluiton after updating to netcore 1.1.2 was changing the project.json file as following:
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": "1.1.2"
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50" //This line must disappear
}
},
"runtimes": { //
"win7-x64": {} //Add this lines
} //
}
After changing this the dependencies will update and viola.
I am a new developer working with ASP.NET 5 (ASP.NET Core). In VS2015 I created a new class library project targeting .NET Platform 5.4 (dotnet5.4), and added the AutoMapper NuGet package, version 4.2.0.
I am getting the following errors, basically for all the System packages:
3>C:\Users\Andrew\OneDrive\Development\Visual Studio\APT\src\Fideles.Service\project.json : .NET Platform 5.4 error NU1001: The dependency fx/Microsoft.CSharp could not be resolved.
3>C:\Users\Andrew\OneDrive\Development\Visual Studio\APT\src\Fideles.Service\project.json : .NET Platform 5.4 error NU1001: The dependency fx/System.Collections could not be resolved.
3>C:\Users\Andrew\OneDrive\Development\Visual Studio\APT\src\Fideles.Service\project.json : .NET Platform 5.4 error NU1001: The dependency fx/System.Collections.Concurrent could not be resolved.
But I think according to the NuGet package description it should be supported:
https://www.nuget.org/packages/AutoMapper/
As you can see from the screenshot these packages seem to be referenced twice; once correctly and once incorrectly with an fx/ prefix:
This is my project.json:
{
"version": "1.0.0-*",
"description": "Fideles.Services Class Library",
"authors": [ "Andrew" ],
"tags": [ "" ],
"projectUrl": "",
"licenseUrl": "",
"frameworks": {
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-*",
"System.Collections": "4.0.11-beta-*",
"System.Linq": "4.0.1-beta-*",
"System.Runtime": "4.0.21-beta-*",
"System.Threading": "4.0.11-beta-*"
}
}
},
"dependencies": {
"AutoMapper": "4.2.0",
"Fideles.Common": "1.0.0-*",
"Fideles.Data": "1.0.0-*"
}
}
Any ideas? Thank you!
The issue is that dotnet5.4 isn't supported by AutoMapper 4.2.0. Depending on what you're targeting it may be possible to change dotnet5.4 to something else (dnxcore50 for example).
I have the same issue on a number of my own libraries and I'm waiting for netstandard to take care of all this.
If you don't mind interrupting your Visual Studio workflow you can get your application to build by doing the following.
Make sure you have the new dotnet CLI installed
(https://dotnet.github.io/getting-started/)
Run dotnet restore from the command line in your project folder
This sorted out the the build errors. I then deleted my lock files and ran Clean and Rebuild on the solution for good measure.
We have to use DNX core 5 and OpenXml, for XLS export, in our app.
It seems like the OpenXml dependency is not supported, according to the error message I got:
Error NU1002 The dependency DocumentFormat.OpenXml 2.5.0 in project does not support framework DNXCore,Version=v5.0. project.json
Here is the part of the project.json associated with the problem:
"frameworks": {
"dnx451": {
"dependencies": { },
"frameworkAssemblies": {
"WindowsBase": "4.0.0.0"
}
},
"dnxcore50": {
"dependencies": {
}
}},
Adding manually the same frameworkAssemblies element to the "dnxcore50" node does not seem to fix the problem.
Removing the "dnxcore50" node makes the app to compile, but this compromises the benefits of dnx Core 5.0 advantages.
This similar question did not properly answer my question :
Open XML in dnx5.0 / aspnext
Does anyone have a solution ?
Unfortunately there is currently no nuget package for the Open Xml SDK.
However, some people are already working on creating such a package:
https://github.com/OfficeDev/Open-XML-SDK/issues/65
Update 24th May.
The community worked for .NET Standard support 😊.
It should work for .NET Core, if not it will be very soon.
Follow the evolution here:
https://dotnet.myget.org/gallery/open-xml-sdk