We are using signed assemblies in autofac-moq like this: https://github.com/autofac/Autofac.Extras.Moq/blob/d38df6d/src/Autofac.Extras.Moq/project.json#L6. It is just a matter of setting the path to snk file in project.json. You can find full set of options in the project.json published schema here: https://github.com/SchemaStore/schemastore/blob/b24ea2f/src/schemas/json/project.json#L239.
Regarding the target framework moniker, TFM question; net4xx, xamrinxx, monoAndroidxx, monoTouchxx they all map to Mono PCL on Unix. Which means you need mono portable class libraries (or full mono) installed on the system running the code. However, when your app targets netstandard1x or netcore1.x, then you have no dependency on mono and it just works on macOS and Linux. See our TravisCI script https://github.com/nunit/dotnet-test-nunit/blob/master/.travis.yml which uses language "generic" to get a base Linux / OSX box, installs some native packages (libicu etc.) and runs the project from there. Similar work was ported to this project: https://github.com/autofac/Autofac.Extras.Moq/blob/develop/.travis.yml (don't mind the invasive JS code, that is for a bug in CLI and I have ranted in dotnet/cli issue tracker a lot about it so expect it to get fixed in vNext of CLI). Other than that pretty straight forward and zero dependency on Mono for netstandard. So if you need to consume full framework on Unix, use net4x and have Mono installed on the system. If you are authoring a new project, then (if possible) probably a good idea to mark CoreFX subset as a baseline to write a pure-portable code and achieve maximum portability. They are closing the gap with all hands on desk in next version of netstandard, but some API methods are permanently retired as those were bad idea to put into the framework in first place (like GetCallingAssembly, which log4net any many other logging libs heavily rely on and the reasoning to have it retired in netstandard can be found here: https://github.com/dotnet/corefx/issues/1784). Other than that, every coming day .NET Core is getting better, CoreCLR getting highly optimized and more cross platform stuff is being incorporated. If you need help in porting your open source lib etc. ping me on GitHub (@jasonwilliams200ok). Build systems is kinda my thing. So happy to chime into any OSS project.. :) BR ________________________________ From: Dominik Psenner <dpsen...@gmail.com> Sent: Sunday, August 21, 2016 7:51:05 PM To: Log4NET Dev Subject: Re: Questions About the .NET Core Build 2016-08-21 18:28 GMT+02:00 Stefan Bodewig <bode...@apache.org<mailto:bode...@apache.org>>: Hi I've got a bunch of questions about the .NET Core build and before I spend more time searching for the anwers I though I may as well ask for help. Version ======= The current version is set as 3.0.0 - why? log4net's next assembly version is 1.2.16. I know the nuget package uses 2.x - probably because it changed the major version when it switched to the new key - but adding another platform shouldn't require a new major version IMHO. I was puzzled by 3.0.0 too. We could however use the opportunity to line up all the different version numbers between the codebase, nuget and .net core extension. 4.x Builds ========== On my Linux box it builds assemblies for net40 and net45 as well. Are these assemblies expected to be the same as the assemblies we build using NAnt? If so, I may be able to use the net45 version built by the dotnet too as NAnt really doesn't seem to want to use 4.5 for me. I can build the net40 and net45 assemblies on my windows 7 machine. We could then compare binary compatibility and a few other things to double check if these binaries are the same. md5 won't do because of the meta data changes that are written into the binary on every build. Signing ======= I'd like to see strong named assemblies using "the new key" is this supported? .NET core supports also strong named assemblies. At least there are a few strong named assemblies out there and a few that are not strong named too. A quick hack in the search engine brought up a few results. -- Dominik Psenner
