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.
Related
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.
Is there a way to configure Visual Studio such that it uses my own self-compiled / self-built (forked) version of the .NET Compiler Platform (Roslyn)?
I want to experiement with C# language extensions in a convenient way.
(I am aware of the fact that this is not an officially supported scenario as of now. Still, I consider it an interesting playground scenario for the community)
With VS2015 Update 1 (which will be available any day now) you will be able to build your Roslyn solution, set "VisualStudioSetup" as your startup project, and just run it. That will run an instance of Visual Studio with the just-built Roslyn substituted for the one built in to VS2015.
See this article that give an example of using modified Roslyn compiler for manipulate the code when compiling
I have two nearly identical DLLS (for the same open source project) - one was pre-compiled, and one was compiled locally by my own compiler (Xamarin Studio/Mono).
The DLL I compiled isn't working with the application that's supposed to be using it (while the pre-built one does), so I grabbed a decompiler to see if I can track down any differences (file sizes were slightly different):
I suspect the reference differences might be the problem. The TOP one is the manually compiled dll. How can I resolve this and make the references identical to the bottom dll's? I've tried using the Mono/.NET 3.5 option in the settings, but it resulted in errors complaining about default parameter specifiers in a bunch of places, so it seems as if it's meant to be compiled w/4.0. Here's a cap of the build settings options (only the Mono/.NET 4.0 option works):
What's causing the differences in assembly references?
Microsoft introduces the multi-targeting feature in its C# compiler, so that C# 4/5 compiler (csc.exe) can generate .NET 2.0/3.0/3.5 compatible assemblies. That's how the pre-compiled assembly comes from.
Unfortunately it is a long time issue for MonoDevelop, that it does not support such multi-targeting. For example, you cannot choose Mono/.NET 3.5 and expect Xamarin Studio/MonoDevelop to use the latest mcs compiler. It always uses the one for .NET 3.5 profile, and fails to compile if you use any C# 4/5 syntax.
You might try to use xbuild at terminal to compile, as xbuild does support multi-targeting. However, you might come across xbuild issues, as it is not yet as capable as MSBuild.
The build machine where I work still uses the .Net 2.0 compiler.
I've set up Visual Studio to target the .Net Framework 2.0, but when I use the keyword var, it's compiling (since the compiler automagically change the type). But it breaks on the build machine compiler.
Is there a way to setup Visual Studio to break on those things, or even force it to use the 2.0 compiler, so that I won't make the mistake to break the build by using "too new" functionalities?
If I remember correctly, each version of .Net was tied to a specific version of DevStudio and it isn't possible to change this. If you need to compile for .Net 2 then you need the VS2005 compiler. One way to solve this is to use makefiles rather than the IDE to build the application and specify explicitly which compiler is used for each file.
Ok I am using Windows and have .Net 3.5 and the Mono 2.6 frameworks installed. I also have installed MonoDevelop and plan on using it. I just need to know if I am setup to use the Mono runtime.
All my projects have build options for Mono/Microsoft.NET 3.5, but in Edit->Prefrences->.NET Runtimes, all I see is Microsoft.NET. How do I add the Mono runtime to this list and make it default? Or do I even need to do this? I would think I would have to since our projects will be run on Linux, but not sure how to 'make sure' I am actually using Mono and not just .NET?
Mono should show up simply by virtue of being installed. You can try reinstalling Mono to see if that helps.
If not, click the "Add" button on the Edit->Preferences->.Net Runtimes page and choose where you installed Mono to, generally it will be something like:
C:\Program Files\Mono-2.6.1
If you want it to be the default, click "Set as Default" while it's highlighted and it should turn bold, indicating it is now the default. There is also a combobox on the main MD toolbar if you want a quicker way of switching between runtimes.
You shouldnt HAVE to build using Mono's compiler on Windows to have your code run on Linux.
As per answers on Performance: Compile in CS, Run in mono on windows and linux, you can compile with any compiler and run with any runtime because the compiled binary is in an Intermediate Language
You just have to be certain that your code, and the libraries that it uses, do not make operating system specific calls, P/Invoke unmanaged DLL's, or make calls to functions that are incomplete in Mono (mind you, these are getting rare)