There are many advantages to discussing debug=true vs debug=false in a production system to debug debugging when publishing to production. Other answers and comments are described in more detail on this (one big advantage that I noticed in MVC4 applications is that JS and CSS packages are minimized when debugging is disabled).
The question that publication in Release mode is sufficient, read below:
If you use ready-made conversion files that come with the new ASP.NET project, then no, you do not need to manually install it. However, if you do not have transformation files or you do not use them, then during production release you must change this parameter.
Basically, when you publish an ASP.NET website, what it will do is create an application, apply the corresponding web.config conversion (based on the configuration selected in the "Settings" section when using "Publish Website" which I assume is where you select the Release mode) and then publish the code in the specified location.
Typically, to get started with transformations, when you create an ASP.NET application in Visual Studio, you will be presented with two transformations for your web.config: web.Debug.config and web.Release.config (you can see them by clicking the extension symbol next to your web.config file).
If you don’t have any transformations, you can create them by right-clicking on the web.config file and selecting “Add Transform Config”, and the transformation files will be created for your various assembly configurations that you have in your solution.
As Maxim Kornilov noted in his answer, out of the box web.Release.config contains this important transformation line: <compilation xdt:Transform="RemoveAttributes(debug)" /> , which tells the application to remove the debug attribute from the <compilation tag, which will publish applications with debugging disabled.
Note. if you do not see that RemoveAttributes(debug) in the configuration conversion that you select when publishing, then the code can be published in debug mode.
If you really want to be sure how the conversion works, review the contents of web.config after posting and you will see the output of the conversion
In addition, there is a tool at http://webconfigtransformationtester.apphb.com/ that allows you to check how the conversion of web.config affects your web.config file.
Finally, I am a big fan of using the build server and am going to publish my code when it is ready to work (fewer people need direct access to the server this way), so converting web.config helps me quite a bit, because I I can change the connection strings based on the environment I'm deploying to, as well as to manage warning messages, etc. for different environments (for example, warning: test system, do not enter real data). Using transformations, the main collection of settings can remain in the web.config file (along with the local dev settings, since pressing F5 usually does not apply the transformation unless you publish it locally for testing), and each environment has its own configuration transformation that lives in source control, and with the same branch, the code can be easily deployed in several environments without the need to change any code.