Now this is interesting!
I just noticed that exceptions in my MVC Views have line-numbers in the stack trace! Which means - my views are compiled with PDB.
I looked at the "Temporary ASP.NET Files" folder on my server - and yes, there are PDB files for every view.
I have <compilation debug="false"/> in my web.config.
Why is this happening and how do I disable that? This is the production server, so I would like to disable the pdb-generation.
I checked my "web.config", "Views/web.config", "machine.config", default "web.config" in windir%\Microsoft.NET\Framework64\[version]\config\ - I think I haven't found any suspicious compiler options there... Where do I look?
Or am I just wasting my time and this is the default option that cannot be changed?
PS. More info, just in case: this is an MVC 4 app, the Views are written in Razor.
Found it!!
Seems like this is the default setting for Razor - it is always compiled with DEBUG option and you can't change it - but I think I found the solution.
Adding this to your machine.config seem to fix the issue:
<configuration>
<system.web>
<deployment retail="true"/>
<system.web>
</configuration>
At least I don't see any more .pdb's in my "Temp ASP.NET Files".
More info about this flag on ScottGu's blog: http://weblogs.asp.net/scottgu/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled
Related
I have run into an issue that when my web application's web.config compilation debug is set to true I am getting a vulnerability error on a security scan.
What I want to determine is if there is a way to have some type of web.config conditional block change the debug setting to use the correct value on debug builds and release builds. I have read that setting the property in each web page itself will do this and don't know if this is in fact true and are there any problems with this?
I would suggest <deployment retail=”true”/>.
You put this element into your machine.config on the production server and it overrides debug=”true” in your web.config and pages. In other words, you can happily use the debug and trace functionality on your developer machines but can be sure it is turned off on the production server. Scott Guthrie recommends this as best practice.
I am getting error when i am publish my ASP.NET Application in localhost using IIS 7.5.
all the pages run perfectly expect on and getting error:-
Compiler Error Message: CS0433: The type 'pages_Default' exists in
both'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\root\785050d7\543e65af\assembly\dl3\6a3d3e87\242bc946_6834cf01\App_Web_zxwcuztt.DLL'
and 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\root\785050d7\543e65af\assembly\dl3\c72e1cad\7d5dd447_6834cf01\App_Web_b5bhtyqt.DLL
Plese Help me to resolve this
Try it:
I set the batch="false" attribute on the compilation section in web.config worked for me.
This tells ASP.NET to dynamically compile individual .aspx/.ascx files into separate assemblies. This avoids the circular reference issue that triggers the exception.
<configuration>
<system.web>
<compilation debug="false" batch="false"></compilation>
</system.web>
</configuration>
Or
You will have a path similar to the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Delete the contents of this entire folder (no harm will be done), then try and Clean and Rebuild your solution.
Or
The problem occurred in a virtual application's bin folder. Looking into this bin-folder you will probably see two files (an information i found here):
App_global.asax.dll
App_global.asax.compiled
Removing these resolves the error. The App_global.asax.dll is generated at runtime too which causes the problem.
I am however still investigating how these files got there, so comments are definitely welcome!
is it possible to set a default page to run when starting debugging? In Visual Studio you can set the default page either through the context menu in Solution Explorer or in the project properties. I did not find something like that in MonoDevelop.
When I am starting debugging the browser will always navigate to the root of the application.
http://localhost:8080
Because there is no default page set in XSP for this application I get an error and always have to correct it manually.
http://localhost:8080/home.aspx
Thanks for your help.
I found a solution. I did not find the xsp.exe.config but it also works when you add the setting either globally in machine.config (residing in /etc/mono/[version]) or by creating a web.config file in your applications root. The values are comma separated.
<appSettings>
<add key="MonoServerDefaultIndexFiles" value="Home.aspx, home.aspx" />
</appSettings>
The help page http://www.mono-project.com/Config does not tell you that a appSettings section is allowed, but I think that the documentation is just incomplete. For example appSettings are used here http://www.mono-project.com/ASP.NET_Settings_Mapping#Inhibiting_the_settings_mapping too.
I'm in the process of converting an existing ASP website into PHP while retaining the ASP website as an older version. Since I'm not an ASP developer, I thought it would be simple as moving the contents of the root directory into its own directory that I've labeled as v1.0 so that the ASP version can be viewed by going to www.mysite.com/v1.0 while the new PHP version (v2.0) can be viewed by going to www.mysite.com
Herein lies the problem. Doing this causes flags all kinds of errors (all related to "Server Error in '/' Application. Runtime errors"). The best I can figure out is that the web.config file needs to be tweaked in the v2.0 directory. Can any of you ASP experts recommend a simple solution to make this happen? I would like to have an empty root directory if possible since the new v2.0 version will be in all PHP and want to "self contain" the ASP version within the v1.0 directory as much as possible.
Thanks!
After a bit of wrangling, finally figured out that I needed to set up v1.0 as its own application under the IIS control panel. Once that was done, then all the contents of the root directory could be moved over to the v1.0 sub-directory and viewed via www.mysite.com/v1.0 -- thanks to Sean! for his help!
Most Classic ASP pages use Server Side Includes, if the site is using a SSI such as:
<!-- #include virtual = "include-file.inc" -->
, then you will need to change all of these to be
<!-- #include virtual = "v1.0/include-file.inc" -->.
I assume that you are using IIS 7 or IIS 7.5, since you are not seeing the actual error, you will need to modify your web.config file.
<configuration>
<system.webServer>
<asp scriptErrorSentToBrowser="true" />
<httpErrors errorMode="Detailed">
</system.webServer>
</configuration>
Reference:
http://learn.iis.net/page.aspx/564/classic-asp-script-error-messages-no-longer-shown-in-web-browser-by-default/
Update
Since it now sounds like you are using ASP.NET, you would need to change your web.config as below to see the full error:
<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
</configuration>
In ASP.Net, if I set up a web application I can configure it to be in release mode but with a website I can only set the configuration to be in debug mode. Why is this?
In web site projects each page is compiled dynamically upon first request. It will compile without debugging symbols unless you specify otherwise in the config file.
A Web Site's debug/release is controlled by the Web.Config file:
<system.web>
...
<compilation debug="true">
...
</compilation>
</system.web>
Set debug="true" for debugging, set debug="false" for release.
Probably because a Web Application compiles the whole website into one DLL. To run and debug pages requires recompiling the entire application. Whereas a website project compiles dynamically at the page level.
For websites one releases the source code to the site, there is no build to be done.
The code is built on site.