Build with Roslyn, but leave the "compile-at-runtime" executables at the door? - asp.net

There has been a lot of talk about the C# compiler Roslyn on StackOverflow and the internet in general. A lot of people ask what and why with Roslyn, while others ask how to get rid of it.
My question pertains to the latter question. As quoted from Kemal Kefeli from here, but frequently iterated verbatim by dozens more (e.g. another example of iteration), in order to remove Roslyn:
When you create a new web project, two NuGet packages automatically added to your project. If you remove them, your problem should be solved. Package names are: "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers".
This approach, however, does not work if you are using the C# 6 features that Roslyn offers. By removing these two nugget packages, you give up any chance of using these features.
My question is, how do you compiler everything with Roslyn, but avoid having any compiler-at-runtime actions occurring and most importantly, the csc.exe, vbc.exe, and VBCSCompiler.exe from being placed in the final release version (in the Roslyn folder).
I am porting over StackOverflow's Opserver into a piece of software. The software allows users to host embedded web servers and web pages from within it. However, the software is very picky about what it allows to be uploaded and executables, like those found in the Roslyn folder, are not allowed to be uploaded and executed at runtime due to security reasons.
Opserver relies on C# 6 features, because if I remove those two NuGet packages, errors sprout up in compile-generated files. But, if I more simply revert to compile strictly with the C#5.0 compiler, then we see this clearly:
If I leave the NuGet packages present and uncheck allow precompiled site to be updatable when publishing, in order to disallow Roslyn with compiling files at runtime as followed by Rutix's comment from here:
Keep in mind that removing these packages [as told by Kemal Kefeli] will break the use of C# 6 features. This could be solved by unchecking "Allow precompiled site to be updatable" which pre-compiles the views ect.
It still generates the executables and the associated DLLs in the Roslyn folder, however significantly less DLLs. How can I possibly remove the Roslyn dependency at runtime and therefore the executables from the outputted version and strictly compile everything at compile-time?

In fully precompiled ASP.NET project ("allow precompiled site to be updatable" disabled) there is no need for compiler to be deployed with app IMHO.
I'm using Roslyn in my .NET 4.6 ASP.NET app (mix of Web Forms and MVC) and precompiled app works just fine after removing Roslyn folder\files from published site...
UPDATE: After a while a found only place where absence of Roslyn in deployment package is the problem a that's accessing ASMX (old style ASP.NET SOAP web service) in browser - "help" page for ASMX is apparently build at runtime even for fully precompiled ASP.NET application and it throws exception (although WS itself runs OK)

Related

Getting "Warning MSB3277: Found conflicts between different versions" during a build

I maintain a ASP.NET WebForms app written by someone else who long since left. Even though the app has about 10 .aspx pages in it, the solution has 12 VB.NET projects. All of the warnings in the build are of this type:
Warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.
I've looked here on SO for help. I came across this post Visual Studio .NET: warning MSB3277: Found conflicts between different versions. However, the answers given referenced NuGet packages. The conflict in this app I maintain is due to one of the 11 other projects within the Visual Studio solution, so I don't believe the answer I found here on SO, applies in this situation.
At first, I thought all I'd have to do was delete the DLLs being created the web application's bin folder. (Not sure why the original developer included the bin folder in the project, but he did.) So, I deleted the DLLs and PDB files, but whenever I build the app, it puts them back into the web application's bin folder. Perhaps that is the way VB.NET (or .NET) works, it just surprises me. Note: the application does build and can be deployed. I've done so. I'd like to get rid of these warnings.
The original developer wrote this using .NET 2. I upgraded it to .NET 4.5.2.

Was the ability to run a .NET Core app from source code removed?

In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.

What default dll's are imported into an asp.net webforms project

I've inherited a legacy code base that doesn't currently compile and has no project or solution file (there are multiple repositories including winforms and asp.net).
I'm not certain what .net version the original code was written in, nor what the project template was, although I know some are web forms.
I'm re-creating new solution and project files to import the code into, but need to find some of the default dll's included in old Visual Studio project templates (e.g. webforms).
Any ideas where I might find this information?
Anyone know an MSDN link with this on it?
P.S. I don't have access to the production code, although it is running in production.

Many ASP.NET Projects - One shared tools library - how to avoid recompiling?

Am I doing this right? I've got many, many separate ASP.NET webforms projects which reference the same main library which contains many tool methods. When I change something in that library, I don't know of a way to make sure that these projects get the updated version of the library. Does auto-refresh detect changes in references even if you don't open the project in Visual Studio? Or does IIS know when a reference has changed and will recompile the project?
Assuming the DLL file is binary compatible (changing an existing method signature is the easiest way to break compatibility) all it comes down is that the newest DLL is in the \bin\ folder. If the site is running it would need to be restarted to pick up the DLL being replaced.
If this is a project reference in your solution, building just does all of this for you.
If this project is outside of your solution, you really should look into using Nuget to distribute this shared project. Even if you only distribute it to yourself. You do not need to host the package publicly on nuget.org

Is it necessary to manually add <AutoGenerateBindingRedirect> metadata to the Core project file to correctly reference assemblies?

I'm using Visual Studio 2013 and MvvmCross to create an Android application using Portable Class Libraries.
I notice in my first view model, CatalogViewModel, some code is highlighted as not referencing the correct assemblies or unable to be resolved (the code builds fine even with these issues).
Examining the .NET Portable Subset assembly in the Object Browser shows various System assemblies included (2.0.5.0 v2.0.50727 & v4.0.30319, 4.0.0.0, 5.0.5.0). Automatic binding redirection for assemblies in .NET Framework 4.5.1 can be enabled or disabled by adding this line to the .csproj file.
<AutoGenerateBindingRedirect>true</AutoGenerateBindingRedirect>
or
<AutoGenerateBindingRedirect>false</AutoGenerateBindingRedirect>
This seems to solve the referencing and redirection issues in the IDE. I haven't found any information about this manual modification to the Core project file in any of the MvvmCross info online I reviewed so I wanted to post a question here to see if anyone had some information or best practices.
No, you shouldn't need AutoGenerateBindingRedirect. This feature is intended to generate binding redirects for non-platform assemblies, such as NuGet packages. Platform assemblies should be unified automatically by Visual Studio / MSBuild.
Which seems to work, since you pointed out:
the code builds fine even with these issues
So this looks like a bug in ReSharper. The fact that adding AutoGenerateBindingRedirect fixes your ReSharper issues might be a side effect of something else.

Resources