I am doing a Web Deployment of my website and I have the merge assemblies property set to true.
For some reason I get the following error.
aspnet_merge : error occurred:
An error occurred when merging assemblies: The relative virtual path 'Global.asax' is not allowed here.
It seems to have something to do with the Global.asax, but I'm not really sure why its getting truncated. My code compiles locally fine, but its only the merge that is messing up.
Any ideas?
As a shot in the dark:
Is it a slash issue? I vaguely remember MSBuild forcibly requiring a trailing slash on some of its properties.
Related
I'm using a nuget package that added xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" into the configuration node of my web.config, which caused my application to break. I resolved this by reverting to a previous version of the package, but I decided to try to navigate to the URL http://schemas.microsoft.com/XML-Document-Transform only to discover that it's an invalid URL.
Now, I know almost nothing about XML... but this doesn't seem right. Did Microsoft recently move this resource? If so, does that break applications that use it? Also, is there a standard procedure when it comes to dealing with invalid schema URLs?
I already search all the web but can't find any problem similar.
Note: The following problem only occurs on production.
In my mvc website if i reload any page multiple times, css, javascript files and images begin to give "500 - Internal Server Error".
It doesn't happen with all the files. Some of the files that are giving the error are: fontawesome.min.css and chartnew.js.
If i call the files directly they work, but if i reload they begin to give the asp default error page "500 - Internal Server Error" without any other details (Already tried without custom errors and using detailed error view).
Any ideas?
Thanks.
Resolved removing this at the webconfig:
<urlCompression doDynamicCompression="true" doStaticCompressions="True" dynamicCompressionBeforeCache="true" />
In my case, I removed WebDav by clicking, Handler Mapping->WebDav module*->Request Restrictions->Verbs-> All verbs.
This will add an entry to your web.config. But then later I decided to remove WebDav from IIS (Remove Features). However, in the web.config, WebDav was still referenced.
Removed all references to WebDav in Web.config, and it worked.
Conclusion: When removing WebDav from IIS, make sure there is no reference to it in web.config.
I have an MVC4 project which worked fine on the (IIS7) server. Then I moved to a new laptop, so of course all the NuGet packages I'd installed had to be uninstalled and reinstalled with different versions in order to get it to build (all I'm using is dotless and whatever dependencies it has, but that appears to be more than nuget was ever designed to cope with).
It now works fine again on my new laptop, but on the server all it does is give me an Error 500. No stack trace. There's nothing in the event log on the server. I set up Failed Request Tracing but the log file directory is empty.
I created a file on the server called test.html:
<p>test</p>
That can't be served either. Error 500 again. Nothing in the failed request log directory, nothing in the event log.
Everything else on that site on that server works fine.
So my question is: Is there any known way to set about diagnosing a situation like this?
UPDATE
It turns out I misconfigured Failed Request Tracing, and had it only enabled for *.aspx. When it's enabled for *, I do get fr00000?.xml in inetpub\logs\FailedReqLogFiles\W3SVC1, one for each failed request.
The problem turns out to have been something broken in web.config
Sounds like some configuration issue with the site and how it's set up in IIS. Without being at your computer, it's hard to say with any certainty, but my best guess based on experience is that you've got a permissions issue with the directory that's being used as the docroot of the site. Make sure IIS_IUSERS has at least read and execute access to that directory.
It turns out I misconfigured Failed Request Tracing, and had it only enabled for *.aspx. Once I had it enabled for *, then for each failed request a sequentially numbered log file was created:
inetpub\logs\FailedReqLogFiles\W3SVC1\fr00000?.xml
...etc. Those files contain a staggering amount of detail.
I searched for "exception" in that xml, and the problem turned out to have been something broken in web.config
So this was pure stupidity on my part.
I'm using Visual Studio 2010 and C# ASP.NET. When I run my project using F5 key, it launches the ASP.NET Development Server, and that's the server I'm using for my work, not IIS.
Problem is, when I get a "Server error in / application" unhandled exception error, the error page has no line numbers, nor source file name. Just an error description and stack trace. For example:
Server Error in '/' Application.
DataField must be specified. [or whatever error message]
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: DataField must be specified.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[etc]
I am compiling in Debug mode. My PDB is being generated in my project's BIN directory. In my project properties, under Web, NTLM authentication is turned off. In my web.config I have the following:
<authentication mode="Forms">
[...]
<customErrors mode="Off"/>
[...]
<compilation debug="true" targetFramework="4.0">.
Also in my project properties, under Build, the Debug configuration is active, and the DEBUG and TRACE constant checkboxes are turned on. Under Advanced, the Internal Compiler Error Reporting is set True, and Debug Info is set to Full.
The user account I am running under has "Debug Programs" privilege enabled in its group's security policy.
I have researched this question here on Stack Overflow and elsewhere, but I can't seem to find a straight answer that fits my situation. One answer I found involved removing a setting "impersonate=true" from web.config, which apparently applies to IIS, but I'm not using IIS, nor do I have this in my config file. I'm using the built-in ASP.NET Development Server which comes with VS 2010, instead of IIS. Another answer said to set up a symbol server, and set the _NT_SYMBOL_PATH env variable, but I don't know if this applies to what I'm doing.
This is really confusing because I'm using default settings and configuration for everything, and it seems like this would be a common problem most developers would encounter. Unless everyone else is using Publish and doing their development via IIS. Incidentally I haven't tried with IIS to see if I get line numbers, yet. But I want to use the built-in ASP.NET Development Server -- I would expect it to show full debug/trace details for exceptions by default, and maybe even integrate with VS 2010 to break on exceptions and let me step through code. But maybe I'm asking for too much. Anyone?
(If you answer with a suggested solution, please first read the details of my settings above, so you can see whether I already have the setting you're suggesting.)
Followup: I tried with IIS and I get line numbers. But this doesn't solve the issue because I want to use the lightweight Development Server instead.
So, I figured out that line numbers were showing up fine when a .CS source file threw an exception, but not when an exception occurred in an .ASPX source file. For the .ASPX itself, the line number and source code excerpt were not appearing at all, whether in IIS or Development Server. (This is not exactly how I had described the issue originally in my question, above, so this clarifies things a bit.) One of my colleagues said this is just the normal behavior, there's no way around it. He implied that you will have to guess which line the exception is on in your ASPX page.
However, after more research, I found a way! I can get the line numbers when an .ASPX file causes an exception. But I still don't understand why this isn't any easier to set up! Like maybe an option at the page or project level, instead of requiring a block of code to be added.
The following code must be in each page's ASPX.CS itself, not in its Master Page, nor in any parent class derived from Page class (which the page may inherit from). This is because if the other classes' Page_Error handlers are called instead, then the call stack is affected, and the most recent entry doesn't pertain to the error. (I was looking into a solution for this too by traversing the call stack. It appears to be possible, but I ran out of time and gave up for now.)
public void Page_Error(object sender, EventArgs e)
{
Exception objErr = Server.GetLastError().GetBaseException();
StackTrace st = new StackTrace(new StackFrame(true));
StackFrame sf = st.GetFrame(0);
Response.Write("File Name: " + sf.GetFileName().ToString() + "<br>");
Response.Write("Method Name: " + sf.GetMethod().Name.ToString() + "<br>");
Response.Write("Error Line Number: " + (sf.GetFileLineNumber() - 1) + "<br>"); // line numbers are offset by 1 for some reason
Response.Write("Error Column Number: " + sf.GetFileColumnNumber().ToString() + "<br>");
Server.ClearError();
}
I've had this intermittent issue when using asp.net. My site is dynamically compiled. Sometimes when I modify a user control my web site complains that it is defined in multiple places. It almost seems like the old control did not get removed from the asp.net temporary files and the updated control is compiled to the same directory so it's defined in multiple places. That would make sense to me except for the fact that I have no control over what is in the Temporary ASP.net Files folder.
I've read that having circular references will cause this. I've made sure that I don't have circular references. Even with the simplest site I've seen this happen.
I've noticed that when using Master Pages this error seems to come up a lot more frequently.
I've read that a hotfix tries to fix this issue but I've gotten this error after applying the hotfix.
If I get the file causing the issue and make an edit to it then the error goes away. Even if I just put a space in the file it will resolve the error.
I can also get the error to resolve sometimes by visiting other pages of the site that might not use the user control and hitting refresh. This does not always work.
If I set the site to debug the error never happens. If I set it so that it comiles on a page by page basis then the error does not happen as much but still happens.
Below is what the error looks like.
Compilation Error
Description: An error occurred during the compilation of a
resource required to service this request. Please review
the following specific error details and modify your
source code appropriately.
Compiler Error Message: CS1595: '_ASP.Header_ascx'
is defined in multiple places; using definition
from 'C:\WINNT\Microsoft.NET\Framework\v1.0.3705\Temporary
ASP.NET Files\root\afwew23d\asdfasd423\asdf23.dll'
Edit:
I'm using .net 2.0 (3.5) even though the error above says 1.0. I got that error from another source since I can't reproduce the issue every time. But the type of error is the same.
Edit 2:
Thanks gisresearch for your research. There was one statement in the link you provided:
One caution even if you have debug=false, is that if you go in and change something in one of your aspx pages, this page will have to be recompiled, but this doesn’t cause an appdomain reload so the whole application is not batch compiled again. This has the effect that the page will now get recompiled separately and get its own dll, so don’t change your aspx pages on a live server too often.
There is a setting in machine.config determining how many recompiles are allowed before the app domain restarts, by default it is set to 15, so after 15 recompilations the app domain will restart, just as it would if you touched the web.config or touched the bin directory.
This seems to say that when debug=false and the site has already been visited and compiled, if you change a page it will only compile that one page. That sounds like it could cause problems. I had thought changing a page or user control would cause the entire app to recompile.
Do you have two user controls with the same file name in diferent Folders of your Web App?
That sometimes will cause this issue.
If I set the site to debug the error
never happens.
when debug=true, the asp.net compiler don’t batch compile, when debug=false it does batch compile and may cause this issue.
The Read this post.
There is a conversation about the same issue.
re: ASP.NET Memory: If your application is in production… then why
is debug=true Monday, April 24, 2006
2:39 PM by Robbie Coleman We did get
an error for a UserControl that it
reported it could not load the
FileName_ascx class due to multiple
versions in the Temp ASP.NET folder.
We identified that we had two user
controls with the same file name in
diferent Folders of the same Web App.
The also had diferent namespaces and
never through this exception until we
set debug="false". We even wiped the
Temp ASP.NET directory clean on an
IISreset.
The only way we could fix the error,
was by renaming the ascx file of one
of the two.
Is this correct...? Was there a better
way to fix this?
BTW... [KissUpText] Tess, your posts
have been very helpfull to our
development team, and we really
appreciate all the information you
have given away. [/KissUpText]
re: ASP.NET Memory: If your application is in production… then why
is debug=true Tuesday, April 25, 2006
1:56 AM by Tess Hi Robbie,
Thanks for the nice comment:)
I am assuming that you are getting
"CS1595:
'UserControls.WebUserControl2' is
defined in multiple places; using
definition from
'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET
Files\usercontrols\293a1a4b\dbb2d387\cisxatg3.dll'
" or similar.
The problem basically occurrs if you
are using src rather than CodeBehind
and your cs or vb files contain a
definition for exactly the same class
in exactly the same namespace. The
error is really the same as what you
would get if you tried to compile a
dll with another class defined twice
in the same namespace.
The reason i am saying it happens when
you use src is because if you would
use CodeBehind you would have gotten
an error at compile time.
If the usercontrols are really the
same I would avoid creating a copy,
and instead using the one from the
other folder. If they are different I
would either give the different names
if possible, and if not, make sure
that the source classes are in
different namespaces, such as
ProjectName.FolderName.MyUserControl
The reason you are seeing it now and
not before is because you are now
batch-compiling everything into one
dll.
Hope this helps.