I'm trying to sign a .net core lib, and I'm just not sure if I did everything correctly
1) using VS Command Promp I called sn -k mykey.snk
2) copied mykey.snk to myproject folder
3) in project.json added keyfile
"frameworks": {
"netstandard1.6": {}
},
"buildOptions": {
"outputName": "MyLib",
"keyFile": "mykey.snk"
}
is this correct, is the library (dll) going to be usable on both .net core and full .net 4.6 apps ?
Yes, this is the correct way. If you look into any ASP.NET Core projects, like Logging, you will find
"buildOptions": {
"keyFile": "../../tools/Key.snk"
...
}
in project.json file, and Key.snk in Tools folder. You also may check .NET Core - strong name assemblies issue.
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'm building an ASP.NET Core Web Application (.Net Framework) and am having a hard time figuring out how to hook unit tests up to it. I am targeting the .net framework version 4.6.1
If I create a regular "Class Library" project targeting 4.6.1, as I would for previous version of MVC, it lets me add references to my MVC project (which is part of the same solution) but any namespaces I add through a using statement report an error that I might be missing a reference or using statement. If I double click on the reference under the "References" section in the solution explorer it tells me that the project can't be found or hasn't been build yet.
I tried creating a "Class Library (.NET Core)" but that complains since I'm targeting .Net Framework and not .NET Core. I edited the class libaries Project.json to have it target the .net framework and that lets me add my references and doesn't complain when I the namespaces in a using statement but none of my tests are discovered by the test runner. I've tried both XUnit and NUnit and they both behave the same.
Is it possible to unit test an ASP.Net Core Web Application targeting the .Net Framework 4.6.1 or do I need to commit to the .NET Core?
Edit to add my test class
Here is my test class stripped down to the bare minimum. TestBank.Services is the class I want to test.
using System;
using TestBank.Services;
using Xunit;
namespace TestBankUnitTests
{
public class Class1
{
[Fact]
public void TestA()
{
Assert.True(false);
}
}
}
and here is my project.json
{
"version": "1.0.0-*",
"dependencies": {
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-build10025",
"TestBank": "1.0.0-*"
},
"frameworks": {
"net461": {
}
}
}
Your project.json needs a testRunner setting. Per the project.json documentation, the testRunner setting not only specifies which test framework to use, but also marks the project as a test project.
Try adding it and see if it finds your tests (verified locally that it will not find tests without this setting in the file)
{
"version": "1.0.0-*",
"dependencies": {
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-build10025",
"TestBank": "1.0.0-*"
},
"frameworks": {
"net461": {
}
},
"testRunner": "xunit"
}
I was having a similar issue and found a solution. I am posting it here in case it helps someone. What I have learned is that using an xproj library targeting net461 to test an Asp.Net Core Project (.Net Framework) project targeting net461 and a Windows class library targeting framework 4.61 works but the setup seems to be very finicky and fragile. The key insight for me came from this thread https://github.com/aspnet/Tooling/issues/245 where #BradRem indicated that the folder structure of the projects seemed to the source of issues.
Initially I tried unsuccessfully to use this folder structure:
src
____Asp.Net Core Project (.Net Framework) project targeting Net461
____Windows class library targeting framework 4.61
test
____Core Library used to run xUnit Tests
But when I tried to run the tests using this folder structure it produced the exception that starts off like this:
Unable to start C:\Program Files\dotnet\dotnet.exe
dotnet-test Error: 0 : [ReportingChannel]: Waiting for message failed System.IO.IOException: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.Stream.ReadByte()
at System.IO.BinaryReader.ReadByte()
at System.IO.BinaryReader.Read7BitEncodedInt()
at System.IO.BinaryReader.ReadString()
at Microsoft.DotNet.Tools.Test.ReportingChannel.ReadMessages()
But when I changed to the following folder structure I was able to get it to work:
src
____Asp.Net Core Project (.Net Framework) project targeting Net461
____Windows class library targeting framework 4.61
____Core Library used to run xUnit Tests
So the key was putting the folder that housed the testing class library in the src folder where the other projects folders were.
That said, the other thing that seemed to make a big difference was to add the references to the other two projects to the Core Library test project at the same time rather than one at a time.
I have found something that works for me.
Inside my test project, my project.json file looks like this:
{
"version": "1.0.0-*",
"testRunner": "xunit",
"dependencies": {
"xunit": "2.2.0-beta2-build3300",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"Ng2a.WebApi": "1.0.0-*"
},
"frameworks": {
"net452": {
}
}
}
'Ng2a.WebApi' is my web api core project. It targets only net452.
The Ng2a.WebApi project.json file looks like this:
"frameworks": {
"net452": {}
},
I want to unit test an asp.net core project that targets the full .net framework. I tried using the "normal" unit test project template and a .net core project as outlined in this blog post, but both attempts fail because the assembly of my web-project cannot be referenced in either of the test projects.
Is there a way to unit test asp.net core apps on the full framework?
Found the solution in the comments section of the same blog post. As I cannot link directly, it is quoted below:
BillyboyD
In case anyone needs to do something similar, I have managed to set this up so I can test my controllers in an ASP.NET Core project that targets the .NET Framework 4.6.1 and also references class libraries that are standard .NET, not .NET core (we will have this hybrid situation for some time!). I am using VS2015 update 3 and .NET Core 1.0. My project.json is:
{
"version": "1.0.0-*",
"testRunner": "mstest",
"dependencies": {
"dotnet-test-mstest": "1.0.1-preview",
"MSTest.TestFramework": "1.0.0-preview",
"MyASP.NetCoreProject": "1.0.0-*"
},
"frameworks": {
"net461": {
"dependencies": {
"MyClassLibrary": {
"target": "project"
}
}
}
}
}
(VS2015 Update 3 + Patch)
I have a plain .NET console application (.NET 4.6) and reference a .NET core class library that targets NetStandard v1.3.
The class library has a reference to Newtonsoft.JSON.
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.6.0",
"Newtonsoft.Json": "9.0.1"
},
"buildOptions": { "platform": "anycpu" },
"frameworks": {
"netstandard1.3": {
"imports": "dnxcore50"
}
}
}
The referenced NewtonSoft.JSON package is deployed here:
C:\Users\UserAccount\.nuget\packages\Newtonsoft.Json\9.0.1
The Exception:
An unhandled exception of type 'System.IO.FileNotFoundException'
occurred in DotNetConsoleApplication.exe
Additional information: Could not load file or assembly
'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral,
PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The
system cannot find the file specified.
I guess the .net core lib would reference the dll from the netstandard1.0 folder.
Creation of NuGet package is a solution but not the easiest one.
Microsoft finally admitted this is a problem and will fix it, expectantly, in NuGet version 4.0.1, the first update to NuGet 4 after VS 2017 ships.
The cleanest workaround now is to add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> to a legacy project. However according to Rob Relyea MS will ignore this property after RTM so another workaround is <PackageReference Update="PlaceholderToConvinceThisProjectToGetTransitivePackageReferenceFromProjectReferences"/>.
Solved 31.07.2016
Create a fresh plain .NET console app (not .NET Core) and a .NET Core class library, without doing any referencing between them upfront.
Scenario:
1. Console app based on .NET 4.6, which references a
2. .Net Core Classlibrary (has a reference to Newtonsoft.JSON v9.01)
The .NET core class library is configured as follows (project.json):
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.6.0",
"Newtonsoft.Json": "9.0.1"
},
"buildOptions": { "platform": "anycpu" },
"frameworks": {
"netstandard1.3": {
"imports": "dnxcore50"
}
}
}
Solution
1.) Create a Nuget package from the .Net core class library project first.
Open the command line as admin.
Go (cd) to the project folder of the .NET core class library project (.xproj).
Run the following command:
dotnet pack
The "pack" parameter will create a nuget package out of the .NET Core class library and copy the package to the debug/release folder, depends on your project configuration.
Copy the nuget package files to a folder where you host your local nuget packages.
I have copied them to:
C:\Users\Admin.nuget\packages\LocalPackages\NetCore46ClassLibrary
Screenshot:
2.) If you don't have a local Nuget feed,you have to create one first!
The local Nuget folder (I named it "LocalPackages") will host your custom Nuget packages. The local Nuget Feed will point to "LocalPackages", which is the root folder for all local packages.
After you have created the local nuget feed and copied the nuget package of your .net core class library somewhere beneath the localPackages folder, you are ready to install your .net core class library nuget package.
3.) Install the .NET Core library Nuget Package into the .NET console app
you now have to open the Package Manager Console again.
Choose Package Source: Local Packages (This is my local feed name, may be different).
And the default project should be your .NET console app.
Install your .net core class library nuget package into the console app, in my case:
install-package NetCore46ClassLibrary
That's it !
My system:
dotnet --version
1.0.0-preview2-003121
Could be that the Newtonsoft assembly is 64 bit and your .Net Core project is 32 bit. Also could be that you have multiple versions of Newtonsoft referenced.
I had the same error recently, after including Newtonsoft.Json 6.0.8 in a dotnet core console app. The solution was to include the System.Runtime.Serialization.Primitives dependancy to the project.json config.
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.0.10-*",
"Newtonsoft.Json": "6.0.8"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"imports": "dnxcore50"
}
}
}
As a workaround solution, In visual studio 2017, you can modify the the NetStandard project .csproj as multi-target:
<TargetFrameworks>netstandard1.3;net461</TargetFrameworks>
Rebuild the solution and the referenced dll (NewtonSoft.JSON) will be copied to bin folder of the console project.
Have a look to my implementation in :Workaround Solution
I'm trying to use System.IO.Compression.ZipArchive in a ASP.NET VNext class library in VS2015 Preview. I added the System.IO.Compression package using NuGet, and it added it to my project.json as a aspnetcore50 dependency.
When I try to use the ZipArchive, the intellisense says is not available in ASP.NET 5.0 but it is available in ASP.NET Core 5.0. If I switch to use ASP.NET Core using the drop down in the top bar, then my code works as expected, but when I choose normal ASP.NET it doesn't work.
I tried manually adding it as a dependency to aspnet50 in the project.json, but that didn't fix it.
I need to use the full CLR over the Core CLR as I need to load assemblies into the AppDomain at run time, and I believe this isn't supported in the Core CLR.
Please could someone explain what's going on here, maybe point me to some articles or blog posts, show me how to fix this.
Update:
I guess a better way or wording this is - the ZipArchive is not available in aspnet50, but it is available in aspnetcore50 when I add the System.IO.Compression NuGet package. Why is this?
They only way that I get the project to compile and work was doing the following in the project.json. I'm not too familiar with the compression library so I did not spend time trying to compress a file. Below you will a sample code that will compile with no issue.
{
"version": "1.0.0-*",
"dependencies": {
},
"frameworks": {
"aspnet50": {
"dependencies": {
},
"frameworkAssemblies": {
"System.IO.Compression": "4.0.0.0"
}
},
"aspnetcore50": {
"dependencies": {
"System.Runtime": "4.0.20-beta-22231",
"System.IO.Compression.ZipFile": "4.0.0-beta-22231",
"System.IO": "4.0.10-beta-22231",
"System.IO.FileSystem": "4.0.0-beta-22231"
}
}
}
}
Sample Code
public static void ZipFile(string path)
{
var data = new MemoryStream(File.ReadAllBytes(path));
var zip = new ZipArchive(data, ZipArchiveMode.Create,false);
zip.CreateEntry(path + ".zip");
}