Playing with .netCore/.netStandard -- disable AssemblyInfo.cs



just did a project with .netCore 1.1, with a few .netstandard 1.6.1 dependent dll’s. I have the same project running under .net4.6.1. Using VS2017RC, used the new .csproj file format (its great to be able to drop files in explorer and see them appear in the project in Visual Studio). I had to comment out all the AssemblyInfo.cs file content; system was complaining about duplications. Is AssemblyInfo.cs passé in the new .netCore/.netstandard world?

So I ran this the .netCore program (a utility that dumps info from a structured storage (OLE) file) both on Ubuntu 16 and MacOS Sierra, and it actually ran! I noticed that the startup of the program is slow (even when it has compiled) [using dotnet run], compared to the .net 4.6.1 running on windows. I will try to measure the actual performance of the program on Linux/Mac .net Core vs Windows .net 4.6.1.

Is there a reason why dotnet build cannot build a native .exe file for the local environment? It feels weird having an .exe project outputting a .dll.

Also, it would be good to be able to load the new .csproj file format into VisualStudio on the Mac. I’m sure that tooling will come at some point in time.



Just like with project.json, the new .Net Core .csprojs generate their own AssemblyInfo. This generated AssemblyInfo can conflict with one you include explicitly. You might want to create an issue about this in the sdk repo (which is where the new .Net Core .csproj lives), with added details about what exactly did you do and how did it fail.

Or you could just add the (currently undocumented) <GenerateAssemblyInfo>false</GenerateAssemblyInfo> property to your .csproj.

There are several things:

  • Creating a native executable (which does not have the .exe extension on Mac or Linux), which runs your application. This way, there is no dependency on having dotnet installed on the target system. This is possible today, but probably isn’t what you’re looking for, since it won’t improve performance (in fact, it’s likely to make it worse on its own).
  • Using crossgen (the equivalent of ngen) to pre-JIT your code. This should improve the startup time and it’s also possible today, but not very straightforward.
  • Full AOT (ahead of time compilation). This is what the corert project aims to do. I think this is closest to what you’re asking, but as far as I know, it’s not ready for production yet.

.NET Foundation Website | Blog | Projects | Code of Conduct