I am just getting my feets wet with the new Roslyn compiler platform and i am not quite sure how its auto-compilation feature work (the save file and refresh your browser). As i understand it, it is the Roslyn compiler service that make it possible to auto-compile code just by saving the file. Is this feature exclusively for asp.net 5 ? if so, how comes? I mean, asp.net 4.6 utilizes the Roslyn compiler as well.
And a quick bonus question on the subject. Does the "auto-compile" recompile the hole assembly or is it smart enough to just change the altered parts?
That feature is exclusively for ASP.NET Core as it requires many other building blocks, not only Roslyn.
Yes, ASP.NET 4.6 uses Roslyn, but it only replaces the old compilers and CodeDOM in order to be backward compatible, nothing more.
Related
I want to be able to call C# code from JavaScript. The mono project used to have a WASM SDK that you could download from their old Jenkins server, but that is no longer public. Existing docs tend to point toward those builds. The Azure Devops builds do not include this SDK. A few messages I've seen on their Github account indicate that they are now focusing on the .NET 6 for WASM. I do not wish to use the Blazor components. Is there a way in .NET 6 to build a minimally sized WASM binary without the Blazor UI?
Yes it's absolutely possible. Blazor does not have a monopoly on C#/WASM and it's far from clear that it's going to wind up being the best long term option (and a lot of evidence it's not).
I recommend starting with the Uno WASM Bootstrap. https://github.com/unoplatform/Uno.Wasm.Bootstrap
2022-06-30 Edit -
More evidence Blazor is not the only game in town nor even at the forefront of innovation here:
https://visualstudiomagazine.com/articles/2022/06/29/uno-platform-4-4.aspx
The Mono WASM SDK is continued in the dotnet/runtime repo. The tooling based on old Packager.exe has evolved into a MSBuild/csproj based solution:
https://github.com/dotnet/runtime/tree/main/src/mono/wasm
samples:
https://github.com/dotnet/runtime/tree/main/src/mono/sample/wasm
The key issue when I trying to use code in a custom project (not within the sample) is that we need to reference a private assembly System.Private.Runtime.InteropServices.JavaScript.dll which is included in Microsoft.NETCore.App.Runtime.browser-wasm. The code is almost the same as WebAssembly.Bindings.dll in old mono wasm sdk.
Here is a screenshot of a WebGL page I created, based on dotnet/runtime/mono/wasm:
BTW there is a viewpoint that the performance of implementing WebGL via calling JavaScript functions from C#, is bad: https://marcoscobena.com/?i=wave-engine-web-performance
NativeAOT-LLVM, an experimental c# compiler not official supported by Microsoft, (https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM) can also compile C# to Wasm without any UI framework requirements. There's a similar question about libraries at Compiling C# project to WebAssembly
It seems that dotnet 7 has improved WASM support. More information is provided in https://devblogs.microsoft.com/dotnet/dotnet-7-wasm/
Here it was written that compilers of different versions are applied sequentially to build the latest version of compiler.
I don't want to use binaries provided by Microsoft. I want to have everything be compiled from source codes.
Which repositories I should compile exactly? Do they all have open source licenses?
The runtime and the compiler for .NET 5.0 are open-source. You can start by going to https://github.com/dotnet/runtime. However, building the runtime requires the compiler (which will be downloaded by running the build script). So there's little you can do to avoid getting binaries that were built by Microsoft. If you're afraid that they're fake (and in some way different from what you would get if you directly built everything from source) you'll probably have to go a different way.
I am tasked with upgrading a somewhat complex C# project from .NET 4.8 to .NET 5. The Windows upgrade assistant went more or less smoothly, and with some cleanup, it looks good, Except for one dependency, which is sadly absolutely not replaceable (within the scope of the job).
So my solution to this would be: Move all the code that interfaces with this dependency to a sub-project which builds for .NET 5 as well as .NET 4.8 (at least in the csproj file), and use that as depencency. Does this actually work?
Visual Studio says that's ok, but I have found absolutely nothing on the topic (and while I believe it could work, it's probably just me wanting that it does).
[Regarding the problem that the result will be an absolute mess: the functionality of this dependency will be obsolete within a year, at which point the sub-project will be removed anyway, sadly the ugrade cannot just wait until then]
can I build a project in .net4.8 and include it in a project building for net5
Maybe? The basic rule is that .Net 5 cannot use .Net 4.x libraries. There may be some exceptions to this rule, but I cannot find a reference to confirm this. And I'm fairly sure it can result in runtime failures if the library tries to use methods not available in .Net 5.
The recommended way would be to port the library to .Net standard 2.0, that way you can use it in both .Net 4.8 and .Net 5 projects without issue. This should be fairly straight forward to port unless you are using UI or other libraries not available in .net standard.
It might be possible to use multi-targeting, i.e. write in your project file that the project should be compiled for both .Net 5 and .Net 4.8. You could use pragmas, (i.e. #if NET48) to include or exclude code sections from either framework. I have not used this feature so I cannot provide much details.
Not entirely certain that this is even a valid question, however if I use VS2015 to open a solution that was originally created and maintained with VS2013, will it be compiled using the Roslyn compiler platform whenever built (within VS2015)?
The solution consists of WPF applications, Console applications, Web Applications, Windows Service applications and of course class libraries - so a good all round selection of options.
If this is not the case, how should I enable the Roslyn compiler for these projects?
Thanks.
If you open in VS2015, it will always use the Roslyn compiler to compile, regardless of the language version switch.
Using the /langversion switch simply tells the Roslyn compiler not to allow new features - it doesn't cause an older compiler to be used.
I've been looking at Roslyn for quite some time now, and I'm curious and excited about it. One thing I noticed is that they mentioned that the compiler is re-written in managed code. This raises the question of whether Roslyn is able to run on non-.NET virtual machines, such as Mono.
I would really love to embed C# scripting using Roslyn in my video games, and to use many of their other features in my applications, but I'm wondering if using Roslyn will break the ability for it to run on Mono.
Has anyone tried running Roslyn on Mono? Is it possible? Why or why not?
To clarify, I'm interested in both whether the managed assembly can run on Mono, and whether it can generate assemblies that mono can run.
Despite it being the furthest thing from Eric's mind, Roslyn has been released as true Open Source (Apache 2.0) and is in fact now cross-platform.
Miguel de Icaza of Xamarin showed it running on Mono at BUILD.
When Roslyn releases, it will become part of Mono. They are already maintaining a branch at the Mono Git repo.
As #Govert has already mentioned in a comment, if you want to embed C# scripting capabilities you should simply use the Mono-equivalent library/tool: Mono-Csharp. (Especially because, even if Roslyn could run on Mono, its licence may dictate that you're not allowed to.)
This tool in the Mono world has existed much earlier than Roslyn BTW, and is open source. Here you have even a Microsoft employee blogging about it and uploading it to Nuget:
http://blog.davidebbo.com/2012/02/quick-fun-with-monos-csharp-compiler-as.html
I hope your game will kick ass!