Shulou(Shulou.com)06/03 Report--

This article mainly introduces what kind of pit will be encountered in NET Core, which can be used for reference by interested friends. I hope you will gain a lot after reading this article.

The first pit conditional compiler

When we write some methods, we usually add some output logs for the Debug schema for us to check, and we also add or modify some specific parameters for the Release schema, but today I encountered this pit when I was writing these.

The code in # if! DEBUG # endif can't change how I change the configuration environment is always gray, which makes me wonder, does VS 2017. NET Core no longer support conditional compilers?

So a new console program was built to test the following, but found that it worked as follows:

You can see here that I am not in a Debug environment, but the # if DEBUG is still a normal color. DEBUG is still gray. After running directly F5, I found that the result was unexpected to me.

The result turned out to be normal, so I suspected that there was something wrong with my vs update, so I created a project in the old .net framework format and found that the old one was good.

Some files under the second pit .NET Core MVC cannot be downloaded.

Using .NET Core MVC to create a site, originally used quite well, but then equipped with app, so directly put the apk file into the site's wwwroot directory, changed the name to app.apk, and then visit: http://127.0.0.1/app.apk returned to me a 404 not find

Because there are still a lot of iis, I immediately thought of one caused by adding mime every day, so I went to the iis site to add, find and exist.

I was confused in an instant, so I went to the request screening to find out if it was banned there, but I found it useless, so I changed the file to app.apk.zip and found that zip could be downloaded.

The attempt file for the third pit. Net Core 2.0 MVC

Since 2.0, it seems that the attempt file has been packaged directly into a dll file, which is not a shtml file after it is released like the traditional mvc, but is compiled into a dll file naming rule is the project name. PrecompiledViews.dll

The fourth pit. Net Core references DLL problem.

In the past, our developers always made some commonly used functions into a separate class library and compiled them into dll for project use, but this didn't seem to work in A. NET Core project.

At first, I wrote a common class library, and added a new class library to the solution to reference the common class library project. There was no exception when I did this, but when I started another vs to create a new solution add project, it was normal to write code in vs after going to reference the dll of the common class library, and the code hints were also available.

But as soon as I pressed F5 to debug, I came out of the pit and failed to find the type or namespace.

The solution is to package the common class libraries to generate NuGet packages

Then add references by managing the NuGet package, but in many cases I don't want to put all the class libraries on nuget.org. I can put the generated nuget package in the Microsoft Visual Studio Offline Packages offline package.

Just put it in the directory corresponding to Microsoft Visual Studio Offline Packages.

Thank you for reading this article carefully. I hope the article "what pits will be encountered in .NET Core" shared by the editor will be helpful to you. At the same time, I also hope that you will support and follow the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.