I am looking to write a few helpers in my own assembly modeled after the helpers in System.web.mvc. My problem is that I cannot use the call to Tagbuilder.ToMvcHtlString since it is internal. So if I return a string it wont be ready for asp.net 4 when it comes.
I dont want to add anything to system.web.mvc as that is a given dll.
return MvcHtmlString.Create(tagBuilder.ToString());
Related
The 'ASP' namespace seems to be a generated because it's not used in the website project's source code, anywhere (or at least not explicitly used by the programmer of the website). I would like to know how it is fully realized.
For example:
Is it the responsibility of MSBuild to drive creation of the ASP namespace and
if so, where is that instruction found? I
know the C# compiler won't create a namespace from nothing of
its own volition, so the ASP namespace must be fed into it,
even if not used by the website programmer. Maybe it's
generated into the source code by a different tool. The
'Temporary ASP.NET Files' folder might have some bearing on it. As you
can see, I want all the gory details in order to unlock and understand
that namespace ...
Visual Studio seems to have tooling that allows the ASP namespace to be used (IntelliSense support for it) but that masks my understanding of it.
How is the 'ASP' namespace realized in a website from start to finish?
(I haven't found a good article that explains all this.)
Here the ASP namespace is shown in .NET Reflector. (This image taken from Rick Strahl's blog)
The ASP. namespace can be used to Load dynamically a custom control with more safe that the cast will works.
You can control what name the custom control can take in the ASP. namespace by placing the ClassName="ControlClass" on the declaration of the name space and the dynamic control now will have a reference to ASP.ControlClass to make a secure cast when you use the LoadControl
You can read the full steps on MSDN http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx
When you do not use the ASP. namespace and left the control takes an automatic name, then the case may fail (I do not know why, but its fail on my sever time to time) The reference that there created are
namespace ASP
{
[CompilerGlobalScope]
public class Control_Class_nameByDirectory : ControlClass
{
[DebuggerNonUserCode]
public ControlClass();
protected override bool SupportAutoEvents { get; }
[DebuggerNonUserCode]
protected override void FrameworkInitialize();
}
}
And when you try to make a cast like (ControlClass)LoadControl("~/module/Control.ascs") it may fail because is recognize it as Control_Class_nameByDirectory and not as ControlClass
Now if you declare the ClassName on the control header as MSD says, the result is the control to get the same ClassName as the one you have define :
namespace ASP
{
[CompilerGlobalScope]
public class ControlClass : global::ControlClass
{
[DebuggerNonUserCode]
public ControlClass();
protected override bool SupportAutoEvents { get; }
[DebuggerNonUserCode]
protected override void FrameworkInitialize();
}
}
and here you can use the ASP.ControlClass to cast the control with out worry if its fail.
So following the steps that described here http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx you can avoid issues like that. (and that I have face them)
The issue of failing to case a custom control with out reference to ASP. namespace have been seen both on Dot net 4.0 and 4.5 versions. And the worst is that is a random failure - meaning that some times is happens, some time not, and I was unable to find the reason.
I'm going to assume that you're looking for the prefix on server control tags... if that's not the case, let me know.
The prefix is registered in the web.config file under configuration/system.Web/pages/controls. You can modify it if you want, or register additional prefixes for your own control libraries.
MSDN info here: http://msdn.microsoft.com/en-us/library/ms164640.aspx
This namespace is used on the code that ASP.NET generates from parsing your .aspx and .ascx files.
I have no idea why you care, though. It's just a namespace. There's nothing "special" about it, and you shouldn't be referencing anything in that namespace.
To understand how all of this works, read "ASP.NET Life Cycle".
The question's simple: how could one use embedded resources in asp.net applications? What are the steps to include a resource in the assembly, and how to reference it? What are the gotchas that could be encountered?
Edit: For a version without referencing Page and ClientScript, see What is the right way to handle Embedded Resources on a Razor View?
After spending a half of a day I've learned these:
to embed a resource one needs to set it's Build Action to Embedded Resource (in VS Solution Explorer rightclick the file -> Properties)
next AsssemblyInfo.vb must be modified to make this resources available for WebResource queries. Add [Assembly: System.Web.UI.WebResource("MyWebResourceProj.Test.css", "text/css")] to AssemblyInfo.vb located in MyProject folder of the project.
The name consists of root namespace/assembly name +'.'+filename. To be 100% sure of the name, use the following code snippet to look it up:
Dim resNames = Assembly.LoadFile("YourDll.dll").GetManifestResourceNames()
Note that the assembly's Root Namespace must be the same as the Assembly Name (this took me about 4 hours to realize. At least with .Net v4 that is the case)
If there are references inside the css ( <%=WebResource("NS.image.jpg")%> ) than pass PerformSubstitution:=true for that css's WebResource attribute.
Referencing the resource can be done with Page.ClientScript.GetWebResourceUrl(GetType(MyWebResourceProj.ConssumingPage), "MyWebResourceProj.Test.css")
Note that instead of GetType(Typename) one could use Me.GetType(), but again, that won't work if the class is inherited, so beware!
Resources:
Debugging ASP.NET 2.0 Web Resources: Decrypting the URL and Getting the Resource Name
Using embedded resources through WebResource.axd is a pain in the neck, as you can see from your own answer. You have to keep assemblyinfo.vb|cs in sync, and it always seems damn near impossible to get all the namespace & assembly names right in all the right places.
When you finally get it to work, your reward is an include script line that that looks like a core memory dump.
I suggest an alternative. Write yourself a very simple web handler (e.g. MyResourceLoader.ashx. Then add a method to your class that simply serves it's own embedded resources, in whatever way you think is meaningful. You can use reflection to get the classes, like WebResource does, or just hardcode whatever you need into your loader, if it's just for a specific purpose. A public method in your class might look like:
public static Stream GetResource(string resourceName) {
// get the resource from myself, which is easy and doesn't require
// anything in assemblyinfo, and return it as a stream. As a bonus,
// you can parse it dynamically or even return things that aren't
// just embedded, but generated completely in code!
}
Or if you decide to make something more general purpose, you can get all fancy and return more data using a class, e.g.
class ResourceInfo
{
public Stream Data;
public string MimeType;
public string FileName;
}
Now you have the ability to serve up your embedded resources any way you want, e.g.
<script language="javascript" src="/MyResourceLoader.ashx/MyControlScript.js">
I think MS made a mess of that WebResource business. Luckily its' pretty straightforward to do your own thing.
I am loading a type from an external assembly and want to create an instance of the type. However, this type/class is setup for constructor injection by objects currently being managed/bound by Ninject. How can I use Ninject to create an instance of this type and inject any constructor dependencies?
Below is how I get this type.
Assembly myAssembly = Assembly.LoadFrom("MyAssembly.dll");
Type type = myAssembly.GetType("IMyType");
Assuming you've created a Kernel, you should be able to create and have it resolved via:
kernel.Get(type)
.... then I read the question.... Assuming MyAssembly.dll has an implementation of IMyType, you need (in your main assembly) :-
kernel.Load( "MyAssembly.dll")
And in your dynamically loaded assembly:-
public class Module : StandardModule
{
public override void Load()
{
Bind<IMyType>().To<MyType>();
}
}
And dont forget to see if MEF is the answer here, as you dont want to go writing reams of explicit plugin management and/or detection logic if you can help it (but if you're just doing straightforward stuff and are only doing the Assembly.LoadFrom() for the purposes of asking the question, you're probably still in Ninject's sweet spot.
Ditto, if you actually need to resolve an interface via Assembly.GetType(), you probably should be using something like dynamic to do the late binding you'll probably have to do (and before you know it you should be using a dynamic language or hosting a scriopting language)
In my page, if i refer
using System.windows.forms;
using System.web.webcontrols.....
Textbox ambiguos refernece error is occured from webcontrols and forms,
how can i rectify this error... but i need those two namespaces in my asp.net page.
Let me first say that I find it a bit odd that you need to reference System.Windows.Forms in an ASP.NET project.
As already posted by ondesertverge, you can fully qualify your types. You can create aliases for the namespaces to save some typing:
using WebForms = System.Web.WebControls;
using WinForms = System.Windows.Forms;
// ...
var textbox = new WebForms.TextBox();
You can fully qualify one of them.
System.Windows.Forms.TextBox
You can alias the namespaces and uses the alias for each type:
using winforms = System.Windows.Forms;
using webForms = System.Web.Webcontrols;
...
winforms::TextBox ...
webforms::TextBox ...
...
Another option is to use the full name for each type (including the namespace), to avoid ambiguity.
i have an microsoft .office.interop.excel(dll) located at an directory d:\abc. now i do not want to add them as an web reference in my projet and call them
rather call the dll dynamically from my code behind(.cs)
is ther any way we can do dynmically
anyhelp would be great
thank you
Yes, but you will need to use reflection because if you don't add the assembly as reference it won't be known at compile time. Take a look at LoadFrom method.
var assembly = Assembly.LoadFrom(#"d:\abc\microsoft.office.interop.excel.dll");
var someType = assembly.GetType("Namespace.Type");
var instance = Activator.CreateInstance(type);
someType.InvokeMember(... // the reflection pain goes on
Take a look in Assembly.Load() method.
I want to discourage you from doing that. It can definitely be done if read the dll into a byte[] and call AppDomain.CurrentDomain.Load(byte[]). However you will find that you can only work with the types of that assembly through reflection. Otherwise your code behind file will not compile. So if at all possible you should add a reference (not a web reference) to the dll.