I have 2 master pages inside one ASP.Net website. It work fine without publishing website. After publishing the website on the web server, one of the master pages works fine, but when I want to access the page that is linked with the second master page it gives me the above error. But the weird thing is that the error paths are in c\ drive of my computer.
When this has happened in the past [rare but I saw it once in production] you need to clear out the contents of your shadow copy folders for your application. These are usually in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files but the error path in your exception details will tell you where.
when copying one web page/user control to create another web page/User Control . After copying one userControl to create another, I neglected to change the partial class name in the .cs of the new userControl and the 'Inherits=' in the .aspx file. Fixing those class names stopped the error from occurring. I suppose the easiest fix to avoid this is to just create new userControls each time using the wizard rather than copying and pasting an existing userControl.
as ex
if we copied the main master page to create another master page, both of them will have the same inherit and that what would create the problem so change the class name and then change the inherit with the new class name or always add new items rather than copy and paste
There are various cs0433 errors that can cause this to occur.
Basically, if you like I did, try and compile the same project with different versions of Visual Studio, they may likely use a different version of the .Net Compilers and libraries.
Therefore, some built assemblies will be duplicated causing differing pointers to the same functionality, but with varying .Net CLR's
What solved it for me, was to recreate the folder from "Virgin Code Files", but with a slightly different name such as "Project1", "Project2", etc..
Then you can rebuild the project from scratch with the correct Visual Studio version, which for me was VS2019 and then "Bob's your uncle :)" No more errors.
Please accept this answer
Related
How do I update references to user controls after putting ascx and aspx files into different folders?
I'm not used to working with ASP.NET Web Forms projects, but I inherited this one. When I first received this Project, every file was directly under the root; no folders whatsoever. I've started putting files into folders and updating the paths.
When I try to load a user control, however, I get this error:
Cannot use a leading .. to exit above the top directory.
My user control is located at:
myProject\controls\Widget.asxc
My page is located at:
myProject\Pages\Activity\AST_Page.aspx
Markup from AST_Page.aspx:
<%# Register TagPrefix="tf" TagName="Cost" Src="..\..\controls\Widget.ascx" %>
My understanding is:
When a user navigates to AST_Page.aspx, the current path is myProject\Pages\Activity\.
Starting a path with ..\..\ should put me at myProject\.
Therefore, ..\..\controls\Widget.ascx actually points to myProject\controls\Widget.asxc.
My Project has access to my myProject\.
If I change ..\..\controls\Widget.ascx to ..\controls\Widget.ascx, I get a different error about not finding the file, which is expected as Widget.ascx is not under myProject\Pages\controls\.
There was a second issue on the page. I had "~/../../" in a src attribute; likely due to an aggressive find and replace.
Edit, this is fixed. Will post answer and mark as answer when my restricted account allows me to do so.
The new control was referencing a code-behind file from another project, this meant the references from the project where I added the user control were no longer specific to the project. Correcting this resolved this issue.
Something very peculiar happened this morning, and I can't resolve it easily.
Working away in Visual Studio, added a new user control (.ascx file), and suddenly all of my current controls that use a MasterPage suddenly require the Global. prefix in their Design.vb files.
Can anyone explain this, is it a visual studio bug?
I have unloaded and reloaded the project to no avail. I have also checked project changes, and the only change is the adding of my new control!
The new control was referencing a code-behind file from another project, this meant the references from the project where I added the user control were no longer specific to the project. Correcting this resolved this issue.
I've copied over the Web Site files to a new WAP project. Made sure that it compiles and it does. The problem I have is that it can't parse the .aspx pages when I perform a convert to WAP. The error simply says it can't parse the .aspx pages.
When I look at one of the .aspx pages, I have the page directive as such but it can't recognize that namespace. That is the namespace I'm using for my new WAP project.
My code-behind pages all have the namespace Instant.Web as well as the project properties is set to Instant.Web for the primary namespace.
so when I go to a page for example, it's not recognizing the Web.Attachment portion of my Inherits.
Here's an example (slightly modified the wording for privacy):
SomeAspxPage.aspx:
<%# Page Language="C#" Inherits="Instant.Web.Attachment" Codebehind="SomeAspxPage.aspx.cs" %>
<asp:Content ID="ctlContent" ContentPlaceHolderID="ctlContentPlaceHolder" runat="Server">
<Frm:Attachment ID="Attachment1" runat="server"/>
</asp:Content>
SomeaspxPage.aspx.cs
namespace Instant.Web
{
public partial class Attachment : Instant.InstantFrm.Pages.Base.UserPage
{
}
}
Also for some reason UserPage in the code-behind isn't showing as a class that you can right-click and go to source. Not sure why because that assembly is definitely in this WAP Project and it's the latest assembly for Instant.InstantFrm
Do not know if it is relevant for your real case, but as for your example, you have an attribute Codebehind="Attachment.aspx.cs" which looks for the file Attachment.aspx.cs, but the file's name is SomeaspxPage.aspx.cs. Usually "file could not be parsed" means the wizard cannot find the matching code-behind file and cannot convert the page.
BTW one more note from here:
Before converting the project files, add references to the Web
application project for assemblies that existed in the Bin folder to
help prevent errors.
It is not clear from your description if you have added the reference to your custom UserPage. If not and that assembly is just copied somewhere into WAP Project it can also cause the converting error.
Try adding a new blank page to your project, check if that can be parsed.
Then in small steps add functionality until you get the page that is the same as the one that is giving you the error.
This should allow you to identify what the problem is.
Based on this quote Warning 126 Unrecognized tag prefix or device filter 'asp' in one of the comments, it sounds like you are missing an Assembly reference in your CSProj file.
Verify that you have System.Web in your References folder of the project.
If it is there, verify the version (directory) it is pulling from is the same as what .NET version you are targeting with your project.
Save and close the solution, then re-open it and try again.
I'm theorizing that VS is caching something and the projects needs to be reloaded.
For WAP site, I'd remove the ASPX layout completely (except the first line, which is required) and output the content using Response.Write in codebehind.
In addition to simplicity, this gives much cleaner output and granular control over the process.
A client has a website, needs a few extra pages, but does not have the source code for the original site.
My first thought is to create a new solution with the new pages, compile them to create as a DLL and then copy the pages and the new DLL to the server. I'm not sure if this will work for the simple reason that I've never had to do it, but it seems quite logical. Is there anything that I'm missing?
I'm using a pre-compiled ASP.NET 2.0 site (i.e., copied to the server using the "Build->Publish Web Site" feature in Visual Studio 2005). I catch and log all errors which are usually quite detailed, but lately I've been getting the following error with no other information:
Could not load the assembly
'App-Web-rp2eml-j'. Make sure that it
is compiled before accessing the page.
Now, that 'App-Web-rp2eml-j' file should be a dll in my bin folder which was created for the pre-compiled site. My main question is, how do I tell what aspx page is looking for that dll? I've tried re-publishing the site, and even completely wiping out the site and re-publishing, but the problem does not go away.
When Googling the problem, most answers about this error message center around making sure IIS is set up to use ASP.NET 2.0 instead of 1.1. This is not my problem.
NOTE 1: The site all seems to work, but obviously there is (at least) one page that is broken which I cannot find.
NOTE 2: The file name above should have underscores instead of dashes, but SO's markup is changing the text between the underscores to italics.
Does the mentioned dll exist in your bin directory? You italicized that portion so I suspect that it doesn't. That could mean that the error is referring to a dll in the Temporary files folder.
This problem can occur if one or more of the dlls in the ASP.NET Temporary files folder are corrupted. Sometimes ASP.NET does not refresh files here if there are no changes in the dll residing in the virtual directory. It happens every once in a while on my server.
My solution is as follows:
Stop IIS services on the server for a minute or so.
Navigate to the ASP.NET Temporary files folder (usually located at "%windir%\Microsoft.NET\Framework\\Temporary ASP.NET Files\MyApplicationName") and clear all files within the folder.
Publish and upload my site to the configured virtual directory.
Restart IIS and other services.
This simple 4-step process has worked very well for me in the past and may be worth a try for you.
To answer your basic question, however, there are two ways to "reverse engineer" a dll:
Load it up in ILDASM and check the contained classes.
Use Reflector to save all the class files contained within the dll to a folder.
However, I doubt if this will solve your problem because each dll could contain many class files and you would not have a clue as to "which ASPX page is looking for that dll".
Maybe you can catch more detailed information on the error with the Global.asax event Application_OnError, so you can watch the stack Trace.