Detailed graphic and text explanations of some pitfalls encountered in .NET Core

Recently, after upgrading .NET Core to 2.0, I started to tinker more and more, but I encountered a lot of pitfalls, so I will record them here.

The first pit is conditional compilation character

When we write some methods, we usually add some output logs for Debug mode so that we can check, and also for Release The mode adds or modifies some specific parameters, but today I encountered this pit while writing these
#if !DEBUG #endif The code in the middle cannot be changed. How can I change the configuration environment? It is always gray, which makes me suspicious. Does VS 2017's .NET Core not support conditional compilation?

So I created a new console program and tested the following, but found that it still worked:

You can see here that I am obviously not Debug environment, but #if DEBUG is still normal color! DEBUG is still grey. After running F5 directly, I found that the result was beyond my surprise

The result was normal. However, I suspected that something went wrong after I updated VS, so I created a project using the old format of .net framework and found that the old one is good again

##The second pitfall is some files under .NET Core MVC Unable to download

##　

I created a site using .NET Core MVC. It was pretty good at first, but then it was equipped with an app, so I put the apk file directly on the website. After downloading the wwwroot directory, I changed the name to app.apk, and then visited: http://127.0.0.1/app.apk. It returned me a 404 not find

Because there is still a lot of iis, so I immediately thought that it was caused by adding mime every day, so I went to the iis site to add it, and found that it existed

I was confused for a moment, so I searched through the request filter to see if it was banned there, but found that it was useless, so I changed the file to app.apk.zip and tried it, and found that the zip could be downloaded.

The third pit .NET Core 2.0 MVC view file

Starting from 2.0, it seems that the view file is directly packaged into a dll file. It is no longer an shtml file after publishing like traditional mvc, but is compiled into a dll file. The naming rule is the project name.PrecompiledViews.dll

##The fourth pitfall .NET Core reference DLL problem

us In the past, some commonly used functions were always made into a separate class library and compiled into dll for project use, but this does not seem to work in .NET Core projects

At first I wrote a Public class library, a new class library is added in the solution to reference the public class library project. There is nothing abnormal when doing this, but when I start another vs to create a new solution and add the project in It is normal to write code in VS after referencing the dll of the public class library, and the code prompts also have

. However, as soon as I press F5 to debug, a trap appears, and it reports that the type or namespace cannot be found

The solution is to package the public class library to generate a NuGet package

Then Add references by managing NuGet packages, but in many cases I don’t want to put some class libraries on nuget.org. I can put the generated nuget packages in Microsoft Visual Studio Offline Packages

Put it into the directory corresponding to Microsoft Visual Studio Offline Packages

The above is the detailed content of Detailed graphic and text explanations of some pitfalls encountered in .NET Core. For more information, please follow other related articles on the PHP Chinese website!