what is the need of assembly ?
why we use them?
is it possible to program without an assembly?
is the assembly is created automatically?
suppose i develop an asp.net web project is there any assembly involved?
could you list example?
To quote the MSDN article on assemblies:
"Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality."
An assembly in .NET is a unit of code that has been compiled together into a single executable, library, or module. Whenever you compile code, you will generate an assembly. I do not believe there is a way to use .NET code without using an assembly.
You can use reflection to learn about the types in an assembly as well as other metadata.
Assemblies are useful because they give us a standard way of putting types into a single file. Assemblies also contain metadata tables that describe the types that are contained within it which aid in development and compiling against them.
I would suggest that you read Assemblies:
Assemblies are the building blocks of
.NET Framework applications; they form
the fundamental unit of deployment,
version control, reuse, activation
scoping, and security permissions. An
assembly is a collection of types and
resources that are built to work
together and form a logical unit of
functionality. An assembly provides
the common language runtime with the
information it needs to be aware of
type implementations. To the runtime,
a type does not exist outside the
context of an assembly.
And Assembly Benefits:
Assemblies are designed to simplify
application deployment and to solve
versioning problems that can occur
with component-based applications.
Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, and security permissions. An assembly is a collection of types that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime (CLR) with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.I do not believe there is a way to use .NET code without using an assembly.
Related
Since version 3.0, .NET installs a bunch of different 'reference assemblies' under C:\Program Files\Reference Assemblies\Microsoft...., to support different profiles (say .NET 3.5 client profile, Silverlight profile). Each of these is a proper .NET assembly that contains only metadata - no IL code - and each assembly is marked with the ReferenceAssemblyAttribute. The metadata is restricted to those types and member available under the applicable profile - that's how intellisense shows a restricted set of types and members. The reference assemblies are not used at runtime.
I learnt a bit about it from this blog post.
I'd like to create and use such a reference assembly for my library.
How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
Are there attributes that control which types are exported to different 'profiles'?
How does the reference assembly resolution at runtime - if I had the reference assembly present in my application directory instead of the 'real' assembly, and not in the GAC at all, would probing continue and my AssemblyResolve event fire so that I can supply the actual assembly at runtime?
Any ideas or pointers to where I could learn more about this would be greatly appreciated.
Update: Looking around a bit, I see the .NET 3.0 'reference assemblies' do seem to have some code, and the Reference Assembly attribute was only added in .NET 4.0. So the behaviour might have changed a bit with the new runtime.
Why? For my Excel-DNA ( http://exceldna.codeplex.com ) add-in library, I create single-file .xll add-in by packing the referenced assemblies into the .xll file as resources. The packed assemblies include the user's add-in code, as well as the Excel-DNA managed library (which might be referenced by the user's assembly).
It sounds rather complicated, but works wonderfully well most of the time - the add-in is a single small file, so no installation of distribution issues. I run into (not unexpected) problems because of different versions - if there is an old version of the Excel-DNA managed library as a file, the runtime will load that instead of the packed one (I never get a chance to interfere with the loading).
I hope to make a reference assembly for my Excel-DNA managed part that users can point to when compiling their add-ins. But if they mistakenly have a version of this assembly at runtime, the runtime should fail to load it, and give me a chance to load the real assembly from resources.
To create a reference assembly, you would add this line to your AssemblyInfo.cs file:
[assembly: ReferenceAssembly]
To load others, you can reference them as usual from your VisualStudio project references, or dynamically at runtime using:
Assembly.ReflectionOnlyLoad()
or
Assembly.ReflectionOnlyLoadFrom()
If you have added a reference to a metadata/reference assembly using VisualStudio, then intellisense and building your project will work just fine, however if you try to execute your application against one, you will get an error:
System.BadImageFormatException: Cannot load a reference assembly for execution.
So the expectation is that at runtime you would substitute in a real assembly that has the same metadata signature.
If you have loaded an assembly dynamically with Assembly.ReflectionOnlyLoad() then you can only do all the reflection operations against it (read the types, methods, properties, attributes, etc, but can not dynamically invoke any of them).
I am curious as to what your use case is for creating a metadata-only assembly. I've never had to do that before, and would love to know if you have found some interesting use for them...
If you are still interested in this possibility, I've made a fork of the il-repack project based on Mono.Cecil which accepts a "/meta" command line argument to generate a metadata only assembly for the public and protected types.
https://github.com/KarimLUCCIN/il-repack/tree/xna
(I tried it on the full XNA Framework and its working afaik ...)
Yes, this is new for .NET 4.0. I'm fairly sure this was done to avoid the nasty versioning problems in the .NET 2.0 service packs. Best example is the WaitHandle.WaitOne(int) overload, added and documented in SP2. A popular overload because it avoids having to guess at the proper value for *exitContext" in the WaitOne(int, bool) overload. Problem is, the program bombs when it is run on a version of 2.0 that's older than SP2. Not a happy diagnostic either. Isolating the reference assemblies ensures that this can't happen again.
I think those reference assemblies were created by starting from a copy of the compiled assemblies (like it was done in previous versions) and running them through a tool that strips the IL from the assembly. That tool is however not available to us, nothing in the bin/netfx 4.0 tools Windows 7.1 SDK subdirectory that could do this. Not exactly a tool that gets used often so it is probably not production quality :)
You might have luck with the Cecil Library (from Mono); I think the implementation allows ILMerge functionality, it might just as well write metadata only assemblies.
I have scanned the code base (documentation is sparse), but haven't found any obvious clues yet...
YYMV
This is not an issue of having a reference to multiple assemblies that have the same type defined (I know to use alias in that scenario).
My issue is that I'm writing a helper library for the System.Data.Services.Client.DataServiceContext type. I would like to let my library be used with any version of that class. The problem I've run into is that it was originally defined in the System.Data.Services.Client.dll assembly with the .NET 3.5 Framework. Since then, Microsoft has released out of band updates in an assembly named Microsoft.Data.Services.Client.dll.
When my library is used by another project, it works fine with the multiple versions of the Microsoft dll, but it won't work with the assembly released with the framework. If I change my library to use the System assembly, then it won't work with the Microsoft assemblies.
I thought about assembly redirects, but that doesn't work if the assembly name is different.
Is anyone aware of a solution to this, or am I going to have to make a decision on which assembly my library will work with (or provide multiple versions of my library)?
I have a framework which contains several assemblies. Multiple assemblies was created due to logical separation of code. This framework is supposed to be distributed to developer as well as end user. Developer are supposed to use few of framework assemblies to develop their modules. But all other assemblies are required to run the modules. Out of several assemblies, I want only few assemblies could be added to project reference and restrict other from being added to developer project references. In other words, I want developer should not be able to use types contained in assemblies which are not meant for plugin development. What is the best way to do that? I want to avoid passing some object to constructor of each type in those assemblies and verify them.
Can I take advantage of AppDomain or anything similar to that, which identifies type is being created by main app or module. If it is not main app, then throw exception or don't initialize. Any change in architecture is suggested.
One option would be to make the types within the "restricted" assemblies internal instead of public, then add InternalsVisibleToAttribute within those restricted assemblies to allow access to them from the other "framework" assemblies.
That way the end developer can still add a reference to the "restricted" assemblies (and probably should do so, in order to make sure they're copied for deployment) but won't be able to use any of the types within those assemblies.
EDIT: Another alternative might be to use ILMerge to build one assembly at the end - so it's a real unit of deployment, even though you originally split it out for separation reasons.
Yet another alternative would be to merge everything into one project and rely on code review, namespaces and common sense to pick up separation violations.
You can make all of the types in the other assemblies internal to prevent them from being ued outside their defining assembly.
You can use the [InternalsVisibleTo] attribute to make them visible to your other assemblies.
I am trying to copy code from one project to another. There is one problem however:
The type 'Microsoft.Practices.EnterpriseLibrary.Data.Sql.SqlDatabase' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null'.
The problem is that I can't find Microsoft.Practices.* anywhere. Anyone know where I can find this file?
If you're trying to copy code from a working project, then that code must already have a reference to Microsoft.Practices.EnterpriseLibrary.Data. Find the reference in Visual Studio and look at its properties.
you need to install EnterpriseLibrary.
From MSDN:
The Microsoft Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development cross-cutting concerns (such as logging, validation, data access, exception handling, and many others). Application blocks are a type of guidance; they are provided as source code, test cases, and documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.
See the 'Downloads' section here and choose "Enterprise Library 3.1 May 2007 (for .NET Framework 2.0 and 3.0)."
What are the implications and suggested scenarios to use either?
Assembly.Load is a dynamic reference since you're dynamically loading an external DLL at run-time. You would consider a static reference more like when you're adding a reference to a .NET project and building the project with that reference in place.
EDIT:
From the MSDN Doc:
The compiler records static references
in the assembly manifest's metadata at
build time.
Hmmm, not sure about this one myself. I'll keep my answer here for now, in the hope of getting more correction comments or seeing better answers.
In reference to:
What are the implications and
suggested scenarios to use either?
Usually, if I use Assembly.Load(), it is because I am developing a pluggable system. Dynamic references facilitate inclusion of assemblies that are not necessarily part of my build.
Instantiating types from a dynamically loaded assembly requires at least some reflection. The amount of reflection necessary can be mitigated by ensuring that dynamically-loaded types implement some known interface or base class (from a statically-loaded assembly).
In short, it's a lot of work to use dynamically loaded assemblies; however, doing so can make an application more flexible by allowing users to develop plug-ins. Just weigh the trade-offs of the anticipated flexibility of dynamic references (which may not be a requirement), and design-time support from Visual Studio for static references.
A practice worth consideration if building a plug-in architecture is to load assemblies in their own AppDomains. Doing so permits you to have finer-grained control over the security permissions of assemblies you may not entirely trust, and provides the added benefit that the assemblies can be unloaded at run-time. Personally, I found working with AppDomains to be labor-intensive; however, if the benefits are required, it's good to know that AppDomains are there.
A dyanamic reference as stated in the MSDN(http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx) references dynamic referencing as loading a reference with only enough information that the runtime has to search for the assembly being loaded. With static references, the location of assemblies(GAC, application direcotry, etc) are known and can be still accomplished using Assembly.load.