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
Related
I am working on a project that requires me to build a .dll file in .NET framework 4.x
I know this would be super easy if I were to use Visial Studio. But I have set my mind on using VS Code as my IDE.
In theory Visual Studio "only" automates the creation of all sorts of metadata and references. So I figured it should be possible to do these things manually. Correct?
Can anybody direct me to where I can find how to do that?
I am working on Windows 10.
Because Code isn't adept at managing a project file (.csproj) - nor should anyone have to - you can actually use the dotnet.exe CLI to create the project and target .NET Framework instead. The only requirement is that .NET Core SDK needs to be installed, even if you use MSBuild because the new SDK-style project requires different targets.
Run: dotnet new classlib -o MyLibrary
Run: code MyLibrary
Open MyLibrary.csproj in Code
Change the line <TargetFramework>v4.5</TargetFramework>
Now you can run dotnet build or msbuild build, and even set up build and test tasks in Code. By default, Ctrl+Alt+B will run a build task, or prompt to create one from a template if none exist yet.
Now you can simply add files without modifying the .csproj file. I participate in many OSS projects that use technique and can easily switch between VS, Code, or even non-IDEs like vim.
It would require from you to type a lot of code and files that are otherwise automatically scaffold (generated) when you create a new project in Visual Studio. Even though VS Code is supportive for .NET framework coding (with the C# plugin), I would advice you to use Visual Studio (the community version would suffice). It has much better support for any .NET framework development.
I recently start to work on a legacy ASP.NET codebase based on .NET framework 4.0. We managed to pass everything from Visual Studio 2012 to VS 2017, updated the build server with a new version of Jenkins and installing .NET framework 4.7.x.
Locally we can write C# code of the newest version (7.3) and the build works (VS doesn't use MSBuild if I remember right), but when we deploy on the build server the build fails because there MSBuild cannot recognize constructs newer than C# 4.0. To avoid mistakes I fixed the lang version to 4.0 (advanced build properties on projects), so if I write too new C# VS blocks me in dev, but we would like to start using new C#.
We also tried to fix C# 7.3 directly in the project (<LangVersion>7.3</LangVersion> in PropertyGroup inside csproj) and the but ToolsVersion property of Project element (csproj) to 14.0, but then building we MSBuild fails with the error:
CS1617: Invalid option ‘6’ for /langversion; must be ISO-1, ISO-2, 3,
4, 5 or Default
Here it's explained that what I want to do it is possible: https://www.dotnetcurry.com/dotnet/1427/build-apps-different-dotnet-framework-versions
No matter which .NET framework version we target in the project, the
C# language version in use will not change. That’s fine because the
vast majority of language features that were introduced in later
versions of the language don’t depend on the CLR or specific APIs.
They are only syntactic sugar and the bytecode generated by the
compiler will still work in .NET framework 2.0.
Anyone have an idea of what mistake are we doing?
The problem was that on the build server MSBuild wasn't properly installed and build scripts got an old one.
Installing Visual Studio 2017 Build tools and fixing the path on the script we solved.
After we had the problem "The “GetReferenceNearestTargetFrameworkTask” task was not found" we solved like explained here: The "GetReferenceNearestTargetFrameworkTask" task was not found
(the right answer depends on what strategy have you used to install VS Buld tools).
Let me explain in more details what I mean. When I was programming on java using eclipse I could attach sources of java to IDE and whenever I ctrl+clicked on some built in class it showed me it's source code not just interface. Is this possible with visual studio 2015 and .NET Core framework? At least there are sources on github, but is there a way to see them in visual studio?
When you create an ASP.NET Core project you are using .NET Core libraries which are already compiled. That's why you don't have access to the source code. Otherwise when you compile your project it means Visual Studio would have to compile the .NET Core framework as well. What a loss of time...
DLLs are located for example under
C:\Program Files\dotnet\sdk\1.0.0-preview2-003131
As you can see, no source code here
You could download the source code from Github, add all the projects to your solution, configure the build pipeline and compile the whole framework everytime you have to run your solution.
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.
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.