Just wanted to know if there is any difference between the two, in the context of a fully trust asp.net mvc 2 application.
The .NET Framework defers loading assemblies into the current AppDomain until they're needed. For example, if you call into a third-party library only from SomeMethod(), the third-party DLL normally won't be loaded until the first time SomeMethod() runs.
AppDomain.GetAssemblies() gives you all assemblies which have already been loaded into the current AppDomain. BuildManager.GetReferencedAssemblies() (This method is only available in the .Net Framework System.Web.dll) returns a list of all assemblies referenced from Web.config and elsewhere, and it loads those assemblies into the current AppDomain.
Here's a worked-out example of the above.
SomeMethod() hasn't yet run.
Call AppDomain.GetAssemblies(), returns a set that does not include ThirdParty.dll.
Call SomeMethod().
Call AppDomain.GetAssemblies(), returns a set that includes ThirdParty.dll.
In this example, the CLR defers loading ThirdParty.dll into the current AppDomain until it's absolutely necessary. And since it's necessary for the execution of SomeMethod(), that's when it gets loaded.
Alternatively:
SomeMethod() hasn't yet run.
Call AppDomain.GetAssemblies(), returns a set that does not include ThirdParty.dll.
Call BuildManager.GetReferencedAssemblies(), returns a set that includes ThirdParty.dll.
Call AppDomain.GetAssemblies(), returns a set that includes ThirdParty.dll.
Here, even though you never called SomeMethod(), the call to BuildManager.GetReferencedAssemblies() loaded the third-party library into the current AppDomain on your behalf.
Of course, this is all subject to certain optimizations, etc., but the general idea holds.
Related
The iOS SDK of Firebase provides the function FIRApp.deleteApp which, according to the documentation:
Cleans up the current FIRApp, freeing associated data and returning its name to the pool for future use.
A similar function is available in the JavaScript SDK but not in the Java or C++ ones.
What this function does and when should I use it?
My understanding is that this function works as a destructor and thus I am supposed to call it when my app is closing. Is it correct? Should I call it on FIRApp.defaultApp too?
A FIRApp object contains references to the configuration data of your Firebase project. It is a lightweight object, mostly using a bit of memory keep those settings available when your application needs them.
Most applications create only a single FIRApp instance for the entire duration of their lifecycle. In such cases the resources will be automatically released when the application exists, and there is no need to explicitly delete the FIRApp instance.
I am in the start of developing an ASP.NET application and want to decide how to cluster functions in different dlls.
Suppose that I have an ASP.NET page that has to dll references, namely A.dll and B.dll. However B.dll uses some methods of A.dll.
Having this scenario, if somebody call my page.aspx where it calls B.dll, another A.dll will be loaded to memory or B.dll will use the same A.dll loaded by my page.aspx ?
Referenced libraries (dll) will be loaded when IIS is starting, some might be loaded on demand i'm not quite sure of that part. But none of your dlls would be loaded twice. dll is a code library, your code base containing definition of your implementation. Don't think of it as an instance of some custom class definition you made. Your dll might contain static classes, extension methods, helpers not only instantiable class definitions
I'm building an application that will load untrusted assemblies for inspection (i.e. retrieval of the assembly full name). For security reasons, I'm trying to think of a way that these assemblies could be written that would allow them to execute code when loaded. I haven't code up with a method yet, but wanted to throw it out here to see if anyone could.
I'm aware that I could load these assemblies into an untrusted app domain, effectively stopping them from doing almost anything, but I wanted to avoid the complexity if it's un-needed.
Specifically, I will be calling Assembly.Load and <LoadedAssebmly>.FullName. Maybe there's a better way to load the assembly name without using the Assembly class?
Thanks,
Matt
First of all, there's the AssemblyName class. It allows you to find the assembly's name without loading it. Second, you can load assemblies using Assembly.ReflectionOnlyLoad, which uses the reflection-only context -- no code can be executed from such an assembly.
Yes, it is possible: .Net: Running code when assembly is loaded
I suggest, you use a method to inspect the assembly, that doesn't load it, i.e. Mono.Cecil
I know why this happens and I want to find a workaround it.
Example: a user control that exist in 2 assemblies, loaded at the same time.
namespace MyNamespace
{
internal class MyUserControl : UserControl
{
}
}
My situation - I want to be able to share user interface control between two web applications which are loaded at the same time in the same application pool. If my user interface class is marked public, then ASP.NET will not like it because it will be duplicated into memory ( CLR uses namespaces as full qualifier for class, and if the same class and namespace is met it more than one assembly, exception is thrown ). I do then mark the class as internal and of course I forget how UI compilation occurs, and I expect it to work. Of course it doesn't because ASP.NET compiles the UI into separate assembly which is dynamic and since I marked the class as internal, it is not visible to the main assembly...
The question that follows is: How can I make dynamic compiled assemblies that ASP.NET generates to view the main application assembly internals? It is very unfortunate that classes and methods I write into my UI controls must always be public! Has anyone met this obstacle in his daily work and found a workaround?
EDIT:
Precompilation is not possible here due to other circumstances.
You can share User Control markup between apps using a Virtual Path Provider (see
http://weblogs.asp.net/scottgu/archive/2005/11/27/431650.aspx and http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx).
You can pull the markup for the control from anywhere - SharePoint uses VPP to get markup from the database, and I use it in some projects to pull from a non-standard location on disk (which is shared between projects).
If your base class is internal, the derived class that ASP.NET generates at runtime will not be able to extend it.
However, I don't understand the issue that you're running into in the first place. Two distinct web applications will always run in different AppDomains (even if they're in the same app pool), and there should be no type conflicts between the AppDomains.
I probably need more details about what you are doing. e.g. what assembly are you compiling your base class into, and why does it end up in two different assemblies?
I have a ASP.net application that is referencing a external assembly that I need to dynamically load and discover any types implementing a known interface. The problem I am having is that the type I reflect does not match the same interface that is running and so I cannot cast it.
Example:
This code is run in ASP.net app.
var assembly = Assembly.LoadFile(Path.Combine(HttpRuntime.BinDirectory, "ExternalAssembly.dll"));
var type = assembly.GetExportedTypes().First<Type>(x => x.Name == "AClass"); // AClass implements IAInterface
var reflectedInterface = type.GetInterface(typeof(IAmAInterface).ToString());
if (reflectedInterface != typeof(IAmAInterface))
throw new Exception("This makes me sad"); // This code gets run
The only difference I can see between the reflected interface I loaded from the bin and the interface returned from typeof is that the typeof assembly has a location in the temp ASP.net path (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\08c43c8b\3adac8cf\assembly\dl3\eb7a4127\0235ea60_a3c8c901\ReflectionTest.DLL)
Thanks Paul Alexander I have changed the code to use the Assembly.Load method not Assembly.LoadFile which solves the problem.
wwilden: I also tried extracting the interface into it's own assembly and this does also solve the problem.
When you use LoadFile the assembly is not loaded into the same context as your other assemblies at runtime so to the CLR interface runtime types are different. You can read more in Suzanne Cook's Debugging Assembly Load Failures.
If the assembly that you're loading is already in the Bin directory - you can load it by name. You don't need to know the exact path as the Bin folder is already in the assembly probing path.
Where is your interface type defined? Does it exist both in the reflected assembly as well as in the application itself? Then you actually have two different interfaces, even though they have the same namespace and name.
What you need to do is extract the interface from the reflected assembly and put it into another assembly that you refer to both from the reflected assembly as well as your application. Then it should work.
Apart from your problem, if you have a lot of assemblies to dynamically load, remember that they will remain in memory until the ASP.NET worker process reloads. This could influence your server's performance.
You could load the assemblies in a separate AppDomain (the smallest unit that is possible to unload), load a proxy class in that AppDomain which you reference with .NET remoting. Once finished, you unload the AppDomain.
There is an interesting article over at CodeProject about a situation like this. Where you have a class that has a structure that is identical with an interface without implementing the interface itself. The article outlines a method of dynamically creating wrapper classes that implement the needed interface. It could be helpful in your situation.