I have written a VirtualPathProvider to change how aspx pages are loaded into my ASP.Net application. As part of this process I have removed Code-Behind files and I am simply ascerting that my page inherits from a particular page class.
eg:
<%# Page Language="C#" AutoEventWireup="true" Inherits="Namespace.PageClass" %>
If I do this I get the following exception:
HttpParseException Could not load type
'Namespace.PageClass'
I have also tried the following:
<%# Page Language="C#" AutoEventWireup="true" Inherits="Namespace.PageClass, AssemblyName" %>
This produces the following error:
HttpParseException
Could not load the assembly
'AssemblyName'. Make sure that it is
compiled before accessing the page.
When the application starts I load the required Assembly into the current App domain:
AppDomain.Current.Load(...)
At the moment I am assuming the problem lies with the BuildManager's ability to resolve the Namespace/Assembly reference.... but if honest... that's a guess :-)
Is anyone able to shed some light on this?
Your page must use the full specified class location - i.e. Inherits="MyNamespace.MyClass, MyAssembly".
Then loading the assembly into the appDomain is not going to help AppDomain resolve it. It doesn't walk the dynamically loaded assemblies. So you must subscribe for the AppDomain.ResolveAssembly event.
private Assembly myDynamicAssembly = null;
protected void Application_Start( object sender, EventArgs e )
{
myDynamicAssembly = Assembly.LoadFrom( Server.MapPath( "MyLocation/MyAssembly.dll" ) );
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler( CurrentDomain_AssemblyResolve );
}
Assembly CurrentDomain_AssemblyResolve( object sender, ResolveEventArgs args )
{
if ( args.Name == "MyAssembly" )
{
return myDynamicAssembly;
}
return null;
}
And you're done. Now the runtime knows how to resolve classes from this dynamically loaded assembly.
Possible causes:
If you refer to any code behind module in .aspx pages or Global.asax page and the web application has'nt been built then you get this error. Just build the application again and make sure that the type Namespace.PageClass is available in one of the web application assemblies.
Use #Assembly directive to link the assembly to the aspx page at compile time.
# Assembly Name="assemblyname" Src="pathname" makes all the assembly's classes and interfaces available for use.
2.Another reason for such an error could be a wrong version of ASP.NET configured in IIS.
To select the correct version of ASP.NET in IIS
Go to Start Menu, click on Run (alternatively use Win Key + R )
Type INetMgr and press enter to open Internet Information Services Application
Expand the tree node displaying local computer name and navigate to Web Sites-->Default Web Site
Right click on Default Web Site node and select the popup menu option Properties
5.Navigate to ASP.NET tab in the properties page and set the correct/latest version.
Related
I have a web application project. I generated the DLL and import it in another project. I implemented VirtualPathProvider.
I followed this web site: http://support.microsoft.com/kb/910441/en-us?spid=8940&sid=global, and everything works until I add another site master.
I added site_export.master and changed its Build Action to Embedded Resource.
I changed my page to use the new site master.
GetManifestResourceStream() returns null when I load site_export.master.
I call GetManifestResourceNames() to check if site_export.master exists in the DLL and it does. It's in the list. All of the name spaces match. I didn't list the name space out here.
Why can't GetManifestResourceStream() load my new site_export.master? It loads site.master just fine. I know my DLL is loaded because I can see other files in the DLL.
Remember the following issues...
Step 1. Build action set to embedded resource see
C#’s GetManifestResourceStream Gotcha
Step 2. Use namespace.resourcename see GetManifestResourceStream() returns null ?
Actually, this method returns null if a private resource in another assembly is accessed and the caller does not have ReflectionPermission with the ReflectionPermissionFlag.MemberAccess flag.
Side-hint. To make sure you're in the right assembly and with right name: dump and evaluate all the resources available in your target assembly
string[] names = assembly.GetManifestResourceNames();
(in my case, I misused a namespace from another assembly)
I did this to make it work:
Step 1: Select the resource (CRDF.xsl in my case) and right click > Properties.
Set Build Action to "EmbeddedResource" and Logical Name to name of your choice, e.g. CRDFXSL.
Step 2 : Change your Source code like this:
Assembly _assembly;
_assembly = Assembly.GetExecutingAssembly();
xslStream = _assembly.GetManifestResourceStream("CRDFXSL");
_xmlReader = XmlReader.Create(xslStream);
Thus everything went smoooooooth..
Hint and Caution:
If the "Assembly name" and "Default namespace" does not match in the project file then also GetManifestResourceStream would return null. GetManifestResourceNames still returns the names of assemblies but during loading the manifest would not work.
Try this:
Dim ctx As Windows.ApplicationModel.Resources.Core.ResourceContext = New Windows.ApplicationModel.Resources.Core.ResourceContext()
ctx.Languages = {Globalization.CultureInfo.CurrentUICulture.Name}
Dim rmap As Windows.ApplicationModel.Resources.Core.ResourceMap = Windows.ApplicationModel.Resources.Core.ResourceManager.Current.MainResourceMap
Dim res = rmap.GetValue("Assets/sample.png", ctx)
Dim resFile = Await res.GetValueAsFileAsync
The Windows.ApplicationModel.Resources.Core.ResourceManager.Current.MainResourceMap list all resources.
I want to create a modular ASP.NET application. Something like, I have a main application that is just some kind of module loader. It only have the one "Default.aspx" page. And, based on the loaded modules, this page will create a menu and links to the pages found in the modules.
I want the modules to be ASP.NET projects packed into dll. So, I want to drop that dll into the "Modules" folder of my main application, it will identify the module, and use reflection to load the modules, inspect them to find the pages, and build a menu from that.
What I've done so far:
In my solution, I have a "DummyModule" project. This project have only 3 pages. Nothing special about it.
And I have another project called "MainApp". Here is the "big deal".
In this project I have a "ModuleLoader" class. When the "LoadModules" method is called, it search for "dll" files in the "Modules" folders of my application. And, using reflection, load these modules. Foreach of these modules, still using reflection, it searches all "Page" types, and stores the names into a list.
On the "Page_Load" method of the "Default.aspx" page, it call de "ModuleLoader" class, gets all modules names and all pages names for each module, and build a menu from that. I created a hyperlink pattern, that have all the information I need to load the right page. That is : "/ModuleName/PageName".
I'm not using the "aspx" extension. OK, so far, so good.
Here is the tricky part.
I've created a HTTPModule called "PageLoaderModule". This modules intercepts all requests, so I can read the URL to identify wich page from wich module I have to load.
And that's exactly what I cannot do and I have no idea how to solve this.
What I'm doing:
public class PageLoaderModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
//clean-up code here.
}
public void Init(HttpApplication context)
{
context.BeginRequest += context_BeginRequest;
}
private void context_BeginRequest(object sender, EventArgs e)
{
var application = (HttpApplication)sender;
if (Regex.IsMatch(application.Request.RawUrl, #"/.+/.+"))
{
var parts = application.Request.RawUrl.Split('/').Where(u => !string.IsNullOrWhiteSpace(u)).ToList();
IHttpHandler page = ModuleManager.GetPage(parts[0], parts[1]);
page.ProcessRequest(application.Context);
}
}
#endregion IHttpModule Members
}
The "GetPage" method, find the correct "Page" type in the specified assembly, create an instance and return the that Page instance.
But when I call the "ProcessRequest" method of the IHTTPHandler interface, it doesn't load the page.
It's possible to do that? Any thoughts?
Edit:
I've tried #Slavo suggestion.
While searching for an anwser, I've found and tried a similar solution, implementing my own VirtualPathProvider and VirtualFile.
It almost worked. The virtual path handle and load the correct page but, when the page is loaded, I got the following error in my browser:
Parser Error Message: Could not load type 'DummyModule.Pages.DummyPage3'.
Source Error:
Line 1: <% # Page Language="C#" AutoEventWireup="true" CodeBehind="DummyPage3.aspx.cs" Inherits="DummyModule.Pages.DummyPage3" %>
So, I don't know if I've done something wrong, or this isn't the solution I'm looking for. So, I tried other option.
I correctly marked the "Build Action" of the ".aspx" file as "Embedded Resource", so it can be accessible as a virtual path. But I still got the error above.
This looks like a case where you would want to write a VirtualPathProvider. This class lets you control the logic, which provides components to the compilation system.
When ASP.NET compiles a page to handle the request, by default it only uses the ASPX file and the code-behind. If you write a custom VirtualPathProvider, you will be able to tell it to do otherwise. So whenever ASP.NET needs to compile a page for a particular path to handle the request, your provider can extract it from an assembly.
Here is a helpful article: http://support.microsoft.com/kb/910441
You should handle the PostMapRequestHandler event in your module and set a custom IHttpHandler to the application.Current.Handler property. Here is an example.
Recently, my team converted ASP.NET project from .NET 1.1 to .NET 2.0. Everything is pretty good so far except for one web page.
This is the error message I got when I tried to open this page:
Server Error in '/' Application.
Parser Error Description: An error
occurred during the parsing of a
resource required to service this
request. Please review the following
specific parse error details and
modify your source file appropriately.
Parser Error Message: Ambiguous match
found.
Source Error:
Line 1: <%# Control Language="c#"
AutoEventWireup="false"
Codebehind="Template.ascx.cs"
Inherits="eReq.Web.WebControls.Template.Template"
TargetSchema="http://schemas.microsoft.com/intellisense/ie5"
%> Line 2: Line 3:
function
ExpandCollapse_Template(inBtn,
inSection, inSectionID) {
Source File:
/WebControls/Template/Template.ascx
Line: 1
-------------------------------------------------------------------------------- Version Information: Microsoft .NET
Framework Version:2.0.50727.3053;
ASP.NET Version:2.0.50727.3053
I tried renaming class and renaming filename but it didn't work.
Anyone have any idea on this?
It may appeared because of different names of components? for example Button1 and button1, it compiles as casesensitive, but executed as caseinsensitive.
In your ASCX file, go through each and every control and change its id. For example,
<asp:TextBox id="foo" />
change it to
<asp:TextBox id="foo1" >
You've probably got a control with an ID that matches a property in your ascx file, so when the compiler is trying to make instance variables its colliding.
I've the same problem and it solved and the solution is in check your code behind and you will find a couple of Controls with the same name:
protected Button Home;
protected System.Web.UI.HtmlControls.HtmlAnchor home;
you have to erase one line or comment it.
The selected answer seems to be the right one.
In my case i found that im using a variable in the codebehind with the same name as a control in the aspx file, just with different case usage.
I'd trawl your web.config for 1.1 and 2.0 references to the same DLL. In most cases that I have gotten this it was System.Web.Extensions.
Also check the #registers in Pages if that fails.
Good luck (it is not a fun bug to find!)
Dan
Same Name Id in aspx file and property inside aspx.cs file
when .aspx page and behind aspx.cs class contains Same property this kind of problem occur. When I am searching the solution for this problem.. not found any useful content. finally I solved the problem by renaming private property name to different inside aspx.cs class attached image as screenshot.
if anyone still facing the problem you may try
Screenshot 1
Screenshot 2
This is due to what can only be described as a defect in System.Web.UI.Util.GetNonPrivateFieldType(Type classType, String fieldName) that allows UI (.aspx/.ascx) fields to compile as case-insensitive but attempts to retrieve them as case-sensitive during the intial parse.
A potential remedy for the time being is to catch it at compile-time with an ms-build task.
I've got two projects, one is a control library and another is my main project. From the control library I am currently using a user control and some css files which are embedded in the control library.
I can use the embedded CSS files in my main project by doing the following from my user control's PreRender event:
// Register the default CSS resource
string includeTemplate = "<link rel='stylesheet' text='text/css' href='{0}' />";
string includeLocation = this.Page.ClientScript.GetWebResourceUrl(this.GetType(), "MyCompany.ControlLibrary.WebNotify.WebNotify.css");
LiteralControl cssInclude = new LiteralControl(String.Format(includeTemplate, includeLocation));
((System.Web.UI.HtmlControls.HtmlHead)Page.Header).Controls.Add(cssInclude);
I thought it would then make sense to include all my javascript files in a similar fashion, so I included the embedded javascript file doing the following:
// Register the js
string includeTemplate = "<script type='text/javascript' src='{0}'></script>";
string includeLocation = this.Page.ClientScript.GetWebResourceUrl(this.GetType(), "MyCompany.ControlLibrary.Scripts.MyScript.js");
LiteralControl jsInclude = new LiteralControl(String.Format(includeTemplate, includeLocation));
((System.Web.UI.HtmlControls.HtmlHead)Page.Header).Controls.Add(jsInclude);
Now, the CSS all works perfectly, however my JS functions throw Object Required exceptions when trying to call them.
Am I going about this the correct way? Or is there a better way of including an embedded js file from another assembly into another project?
Personnally, as others have suggested, use some tools such as FireBug for Firefox, Fiddler, or the Developer Tools for Internet Explorer to check what calls are being made to your servers, and what responses they are sending back - that's what BigBlondeViking's referring to.
I'd also check that you have marked the JS file as "build" in the solution - rather than the default of "take no action".
However, there is indeed a cleaner way of adding embedded script resouces, the ClientScriptManager's "RegisterClientScriptResource" method:
// Get a ClientScriptManager reference from the Page class.
ClientScriptManager cs = Page.ClientScript;
// Register the client resource with the page.
cs.RegisterClientScriptResource(rstype,
"MyCompany.ControlLibrary.Scripts.MyScript.js");
Seems fine; however, at this point I'd really be using client tools to determine whether or not everything's getting there and being used (fiddler/ie toolbar/firebug/etc).
If I had to guess, I would say your code is working, but whatever browser you're using is ignoring the javascript due to the script tag not having a closing tag (i.e. <script></script> opposed to <script />); for some reason some browsers are picky about that
How do I obtain the version number of the calling web application in a referenced assembly?
I've tried using System.Reflection.Assembly.GetCallingAssembly().GetName() but it just gives me the dynamically compiled assembly (returning a version number of 0.0.0.0).
UPDATE: In my case I needed a solution that did not require a reference back to a class within the web application assembly. Jason's answer below (marked as accepted) fulfils this requirement - a lot of others submitted here don't.
Here is some code I use that supports getting the application's "main" assembly from either Web or non-web apps, you can then use GetName().Version to get the version.
It first tries GetEntryAssembly() for non-web apps. This returns null under ASP.NET.
It then looks at HttpContext.Current to determine if this is a web application. It then uses the Type of the current HttpHandler - but this type's assembly might be a generated ASP.NET assembly if the call is made from with an ASPX page, so it traverses the HttpHandler's BaseType chain until it finds a type that isn't in the namespace that ASP.NET uses for its generated types ("ASP").
This will usually be a type in your main assembly (eg. The Page in your code-behind file). We can then use the Assembly of that Type.
If all else fails then fall back to GetExecutingAssembly().
There are still potential problems with this approach but it works in our applications.
private const string AspNetNamespace = "ASP";
private static Assembly getApplicationAssembly()
{
// Try the EntryAssembly, this doesn't work for ASP.NET classic pipeline (untested on integrated)
Assembly ass = Assembly.GetEntryAssembly();
// Look for web application assembly
HttpContext ctx = HttpContext.Current;
if (ctx != null)
ass = getWebApplicationAssembly(ctx);
// Fallback to executing assembly
return ass ?? (Assembly.GetExecutingAssembly());
}
private static Assembly getWebApplicationAssembly(HttpContext context)
{
Guard.AgainstNullArgument(context);
object app = context.ApplicationInstance;
if (app == null) return null;
Type type = app.GetType();
while (type != null && type != typeof(object) && type.Namespace == AspNetNamespace)
type = type.BaseType;
return type.Assembly;
}
UPDATE:
I've rolled this code up into a small project on GitHub and NuGet.
I find that the simplest one-liner way to get the version of your "main" assembly (instead of the dynamic one) is:
typeof(MyMainClass).Assembly.GetName().Version
Use your top-level class, which isn't likely to ever "change its meaning" or to be replaced as part of a refactoring effort, as MyMainClass. You know in which assembly this very class is defined and there can no longer be confusion as to where the version number comes from.
I prefer the Web.Config to store the current version of the site.
You can also try create an AssemblyInfo.cs file in the web application root that has the following:
using System.Reflection;
using System.Runtime.CompilerServices;
...
[assembly: AssemblyVersion("1.0.*")]
...
then access the value via the code like this:
System.Reflection.Assembly.GetExecutingAssembly()
Here is more informaiton on the AssemblyInfo class.
To add to the responders that have already posted. In order to get the assembly version in an ASP.Net web application you need to place a method in the code behind file similar to:
protected string GetApplicationVersion() {
return System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
}
In the ASPX page you want to display the version number simply place:
<%= GetApplicationVersion() %>
Just in case anyone is still interested; this should do the trick and should be a tad safer than just taking the BaseType of ApplicationInstance to get your hands on the Global.asax implementation.
Global.asax is always compiled into the same assembly as the assembly attributes from AssemblyInfo.cs, so this should work for all web applications that define a Global.asax.
For those that don't define their own Global.asax, it will fall back to the version of the generated global_asax type, which is always 0.0.0.0, and for applications that aren't web applications, it will just return no version at all.
Bonus; using the BuildManager class does not require an active HttpContext instance, which means you should be able to use this from application startup code as well.
public static Version GetHttpApplicationVersion() {
Type lBase = typeof(HttpApplication);
Type lType = BuildManager.GetGlobalAsaxType();
if (lBase.IsAssignableFrom(lType))
{
while (lType.BaseType != lBase) { lType = lType.BaseType; }
return lType.Assembly.GetName().Version;
}
else
{
return null;
}
}
HttpContext.Current.ApplicationInstance is derived from the class in the global.asax.cs. You can do the following
var instance = HttpContext.Current.ApplicationInstance;
Assembly asm = instance.GetType().BaseType.Assembly;
System.Version asmVersion = asm.GetName().Version;
It works both in ASP.NET (ASPX) and ASP.NET MVC
I encountered a similar problem, and thought you might find the solution useful.
I needed to report the current application version (of a web application project) from a custom server control, where the server control was contained in a different library. The problem was that the "easiest" assembly getters did not provide the right assembly.
Assembly.GetExecutingAssembly() returned the assembly containing the control; not the application assembly.
Assembly.GetCallingAssembly() returned different assemblies depending on where I was at in the call tree; usually System.Web, and sometimes the assembly containing the control.
Assembly.GetEntryAssembly() returned null.
new StackTrace().GetFrames()[idx].GetMethod().DeclaringType.Assembly retrieves the assembly of a frame in the stack trace at index idx; however, besides being inelegant, expensive, and prone to miscalculation on the frame index, it is possible for the stack trace to not contain any calls to the application assembly.
Assembly.GetAssembly(Page.GetType()) scored me the App_Web_##$##$%# assembly containing the dynamically generated page. Of course, the dynamic page inherits a class from my application assembly, so that led to the final solution:
Assembly.GetAssembly(Page.GetType().BaseType)
With the assembly reference in hand, you can drill to the version through its name:
var version = Assembly.GetAssembly(Page.GetType().BaseType)
.GetName()
.Version;
Now, this solution works because I had a reference to a type from the application assembly. We don't use any pages that do not inherit from a code behind, so it happens to be effective for us, but your mileage may vary if your organization's coding practices are different.
Happy coding!
Version version = new Version(Application.ProductVersion);
string message = version.ToString();
Some info here: http://www.velocityreviews.com/forums/showpost.php?p=487050&postcount=8
in asp.net 2.0 each page is built into it own assembly, so only the dll
the AssemblyInfo.cs is built into will
return the correct answer. just add a
static method to AssemblyInfo.cs that
returns the version info, and call
this method from your other pages.
-- bruce (sqlwork.com)
But I wrote a simple method to do that:
public static string GetSystemVersion(HttpServerUtility server)
{
System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
doc.Load(server.MapPath("~/web.config"));
System.Xml.XmlNamespaceManager ns = new System.Xml.XmlNamespaceManager(doc.NameTable);
ns.AddNamespace("bla", "http://schemas.microsoft.com/.NetConfiguration/v2.0");
System.Xml.XmlNode node = doc.SelectSingleNode("/bla:configuration/bla:system.web/bla:authentication/bla:forms[#name]", ns);
string projectName = "";
if (node != null && node.Attributes != null && node.Attributes.GetNamedItem("name") != null)
projectName = node.Attributes.GetNamedItem("name").Value; //in my case, that value is identical to the project name (projetname.dll)
else
return "";
Assembly assembly = Assembly.Load(projectName);
return assembly.GetName().Version.ToString();
}
If you are looking for this from a web control, one hack is to find the type of the code-behind Page (ie. the class that inherits from System.Web.UI.Page). This is normally in the consumer's web assembly.
Type current, last;
current = Page.GetType();
do
{
last = current;
current = current.BaseType;
} while (current != null && current != typeof(System.Web.UI.Page));
return last;
I hope there is a better way.
The question states with no reference (instances) it did not (originally) say with no knowledge of web application types.
EDIT the OP clarified to state that yes they do really require no knowledge of types within the calling web assembly, so the answer is appropriate. However I would seriously consider refactoring such a solution such that the version is passed into the other assembly.
For most people in this scenario if you know the custom HttpApplication type:
typeof(MyHttpApplication).Assembly.GetName().Version
and if you only have a dynamic generated type:
typeof(DynamiclyGeneratedTypeFromWebApp).BaseType.Assembly.GetName().Version
Stop voting me down for this answer :)
So, I had to get the Assembly from a referenced dll.
In the asp.NET MVC/WebAPI world, there is always going to be at least one class which inherits from System.Web.HttpWebApplication. The implementation below searches for that class.
using System;
using System.Linq;
static Assembly GetWebAssembly() => AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(a => a.GetExportedTypes().Any(t => t.BaseType?.FullName == "System.Web.HttpApplication"));
The above uses System.Linq in order to find that relationship, but this can also be implemented without.
First, we get all loaded assemblies
AppDomain.CurrentDomain.GetAssemblies()
Then, enumerate through the IEnumerable<Assembly>, and get all of the types directly located in the assembly.
a.GetExportedTypes()
Then, see if any of the types inherit from System.Web.HttpWebApplication
t.BaseType?.FullName == "System.Web.HttpApplication"
In my implementation, I ensured this code would only be called once, but if that is not guaranteed, I'd highly wrapping this in a Lazy<T> or other cached lazy load implementation as it is rather expensive to keep performing the blind search.
using System;
using System.Linq;
// original method
private static Assembly GetWebAssembly() => AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(a => a.GetExportedTypes().Any(t => t.BaseType?.FullName == "System.Web.HttpApplication"));
// lazy load implementation
private static Lazy<Assembly> _webAssembly = new Lazy<Assembly>(GetWebAssembly);
public static Assembly WebAssembly { get => _webAssembly.Value; }