I'm really not sure whether .net dll also have entry point like c++ dll generally have.
How can i see if .net dll have entry point or not.
I read somewhere that a WIN32 dlls can have entry-points, dot-net class-libraries dont.
Thanks,
It is an obscure subject, I'll go through it at breakneck speed. Every .NET assembly has an unmanaged entrypoint, 5 bytes of machine code (9 if built for x64) that serve as the entrypoint marked in the PE32 executable file header. Nothing but a JMP instruction, an EXE jumps to _CorExeMain() and a DLL jumps to _CorDllMain(). These functions are located in mscoree.dll and ensure that the CLR is loaded and initialized so it can execute managed code.
These entrypoints help to run managed program without having to start the VM host explicitly. Avoids the need for, say, mono.exe or java.exe. They are not actually used anymore on modern Windows versions, the OS has awareness of an executable file containing a .NET manifest and the loader passes the job to a loader shim, mscoree.dll again. This awareness is necessary to implement the considerable trick of erecting a 64-bit process out an EXE that contains a 32-bit PE32 header. Mscoree.dll patches internal loader data structures to accomplish this feat.
Each .NET assembly also contains a managed entrypoint, listed in the manifest header. Called by the CLR right after it loaded the assembly. An EXE always has one, it points to the Main() method and the compiler ensures that you can't forget to write one. A DLL might have one, a mixed-mode assembly always has one for example. Points to a module initializer located in the <Module> class, the C++/CLI compiler uses it to ensure that the CRT (C runtime library) is initialized before any managed code can execute.
No, .NET DLL assemblies do not have a DllMain the way an unmanaged DLL would. However, all of the behaviors that one would implement in DllMain can generally be implemented using various .NET constructs. For example:
A class static constructor gives you a chance to initialize static members before the type is used
Instance initialization (constructor, field initializers) allow you to initialize instance data before the instance is used
Implementing the IDisposable interface gives you deterministic cleanup. Implementing a finalizer gives you the possibility (but not the guarantee) of non-deterministic cleanup (i.e. before the object is garbage-collected)
The AppDomain has the DomainUnload and ProcessExit events which can give you the chance to run cleanup code as the app domain or process is being closed.
Related
In visual studio when we compile the source code it will generate a byte code then when we build it,create a dll file.I have stuck how the byte code(common intermidiate clanguage) is getting execute by the .net framwork.My understand both CIL and DLL are equal but iam not sure about it.please clarify me boss.
In short, when a .Net language compiler compiles a project, it is turned into either a .Net module, or an assembly. Either of them contain IL (Intermediate Language) code. A .Net module alone is not usable, as it must be included in an assembly. (.Net modules are not commonly used. Most commonly, the dll you get from compiling a project is a one module assembly).
Once you "install" this assembly on a target machine, you have two options:
It can either be installed as is, i.e. the Dll contains IL. Only during execution, a component of .Net runtime, called Jitter will convert it to machine code (native assembly), as the code is executed. The process of converting IL to native machine code is repeated each time the assembly is loaded for execution, for each new process.
It can be converted to machine code during installation, (using tools like ngen). With each execution, machine code is ready to be executed, and hence would provide faster startup / first time execution of methods.
Note: The topic in general is broad, and this is 10,000 ft level overview of the process. There are many details, and up-coming technologies like .Net Native have been left out, to keep this answer simple and most relevant to the way the question has been posed.
In simple words,
C# -> C# compiler (compile time) -> Assembly (DLL/EXE) or .net Module (MSIL form)
Assembly -> JIT compiler (run time) -> machine code (binary form)
For more details,
http://msdn.microsoft.com/en-in/library/ht8ecch6(v=vs.90).aspx
The Common Intermediate Language (CIL) code in the .NET framework is the .DLL and .EXE files that you get once Source Code is compiled by the compiler.
The compilation process, in simple terms, have roughly 3 main code stages:
Source Code (Main input to the compiler)
Assembly code/Byte Code (Intermediate result)
Machine Code/Native Code (Final Output that undergoes actual execution)
.DLL or .EXE files fall under 2nd stage.
.DLL is known as library assemblies and .EXE is known as process assemblies. Both are in CIL form.
A process assembly represents a process that will use classes defined in library assemblies.
This means that CIL and DLL are not exactly "equal" as CIL comes in two forms - .DLL (static/library assembly) and .EXE(executable/process assembly).
So, in reality, the .DLL file or the .EXE files (CIL form) are usually ported to a client computer that has the .NET framework installed (indicating that the CLR which has the JIT Compiler in it, is present on it) where, on the surface level, it seems that once you click the .EXE file, it gets executed, but in reality, the CLR(JIT) converts the .DLL/.EXE once this file is clicked, to machine code which finally gets executed in the backend.
For more details, check:
https://en.wikipedia.org/wiki/Common_Intermediate_Language
https://en.wikipedia.org/wiki/Assembly_%28CLI%29
I have created a dll in c#. I added a reference to this dll in MATLAB as shown below. Everything works fine. The problem is that when I want to update my dll I have to close MATLAB otherwise I cannot rebuild my dll, which is rather annoying. How in MATLAB can I remove the reference to this dll - I thought there would just be a line of code to do this?
% add reference to dll
cls = NET.addAssembly('C:\MyFolder\MyDllFolder\bin\Debug\MyDll.dll');
% reference my class
mycls = MyNameSpace.MyClass();
As a workaround, you can start a new Matlab instance from Matlab itself with a system call and the Matlab command line options and only load the libraries in the new instance. This is described in an answer to the qestion: Release a .NET assembly from MATLAB
Have you tried cls.delete and then add the reference again?
I seem to remember clear classes being useful as well. Sorry I can't be more definitive, I don't have Matlab handy to set up an example.
Edit
Looks like I was wrong, according to this link, "you cannot unload an assembly from MATLAB."
If the most important thing is the downtime while an assembly is being swapped, then you can do this without having to load a new MATLAB instance at all (which is very slow).
Even in pure .NET, it's not possible to unload an assembly from an AppDomain. Too much state is affected by the JIT process -- bits of code from that assembly could have been inlined into many other functions. This is actually one of the big reasons for having the AppDomain feature in the first place.
So, you will need a .NET assembly that acts as a wrapper and never changes. Its function will be to create an AppDomain and load the assembly to test into that child AppDomain. And, when it changes, to destroy the child AppDomain and create a new one.
It's complicated, but isolates MATLAB from the complexity.
I'm trying to add Windows/System32/Shell32.dll DLL to my project. The issue is, it copies the reference to the directory! Since this is a windows file, it shouldn't have to come with me if I were to deploy my application.
I have tried stopping it from copying to the directory, tried looking for how to embed the resource in the application and even added reference paths to System32. It seems so much more challenging than the program just using the local DLL from the system...
What can I do?
Shell32.dll is a COM component. You should not get a copy of it in your project. What you get instead is Interop.Shell32.dll. Which is a .NET assembly, not a copy of Shell32.dll. It contains the COM interface and class declarations, converted from the type library definition inside Shell32.dll to friendly .NET declarations that the CLR knows how to easily handle.
This is an optimization, it avoids having to make the conversion at runtime. Which is expensive, subject to various options (check the MSDN docs for Tlbimp.exe) and may easily fail because there is no general requirement that the type library is also available on the target machine.
You must deploy Interop.Shell32.dll to the target machine, just like you do with any .NET class libraries you'd use.
Do note that this interop library is no longer needed on .NET 4 and VS2010. Which acquired the "Embed Interop Types" feature. In other words, instead of keeping the interop types in a separate assembly, the C# and VB.NET compilers can now embed them in your program. Very highly recommended, just set the option to True in the Properties window view of the Shell32 reference.
This question is a sequel of this question
We're creating a dll, written in C++, providing access to some hardware. This dll implements and is accessed using COM interfaces. We also have a C# program that uses this dll through the COM objects.
We're having an issue with the versions. Indeed, when running the C# program, it absolutely wants to use the exact COM/C++ dll version it used when compiling. I.e. if the C# program was compiled using COM/C++ dll 1.2.3.4, then the program will refuse to run with COM/C++ dll 1.2.3.5.
Unhandled Exception: System.TypeInitializationException: The type initializer for 'MyDllVerify.App' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'MyCorp.MyDll.Interop, Version=1.2.3.4, Culture
=neutral, PublicKeyToken=ced78d295d1e0f2b' or one of its dependencies. The system cannot find the file specified.
File name: 'MyCorp.MyDll.Interop, Version=1.2.3.4, Culture=neutral, PublicKey Token=ced78d295d1e0f2b' at MyDllVerify.App..cctor()
I'd like to instruct the C# program to use any COM/C++ dll with version 1.2.anything.
Where can I configure this in the C# project?
I would suggest you to not directly reference to the COM-dll in your C# project. If you do that, at build time there is always a new COM-interop-dll generated. This can lead to a lot of problems.
It would be a better approach to create a COM-interop-dll, store it in your library folder and reference this library in your C# project. Keep this COM-interop-dll as static as possible. If you do it like that, you can replace the used COM-dll as much as you want, as long as your interfaces do not change.
You could try to manipulate this interop assembly and make the version checking for 1.2.* there, if you realy want that (I would not recommend to that, it could cause serious confusion).
Explanation:
The COM-interop-dll is a regular .NET assembly. It works like a wrapper between your C# code and the COM-C++-code you want to use in the C# code.
The COM-interop-dll don't have to be registered for COM. You can install this assembly so many times you like. But it requires that your COM-dll is registered for COM.
Useful tools:
tlbimp
regasm
sn
Nothing is different from the way I documented it in your previous question. You still use <bindingRedirect> to allow the wrong version of the interop assembly to be loaded.
It is fairly unlikely to work in practice, messing with DLL Hell when you use COM is extremely unwise. If you use early binding then COM has no way to verify that you are calling the correct method. Very unlike .NET where the jitter can make checks like these at runtime from the metadata in the assembly. If the C++ programmer did it right then he changed the guids of the types that he changed. Which will make your code bomb with E_NOINTERFACE since you'll use the guid of the old version.
If he didn't, unfortunately way too common, then your program is liable to crash with something nasty like an AccessViolationException. Or worse, it won't crash but will call the completely wrong method.
The failure mode is more benign when you use late binding, you'll get one of the IDispatch errors when the method doesn't exist or if its arguments have changed. Not that this ultimately solves anything, you still have a program that doesn't work. Mess with DLL Hell like this only if you like to live dangerously.
Our .NET 3.5 C# application creates multiple appdomains. Each appdomain loads the same unmanaged 3rd party dll. This dll reads a configuration file upon initialization. If the configuration changes during runtime, the dll must be unloaded and loaded again. This dll is not in our scope to rewrite correctly.
Does each appdomain have access to a separtate copy of this unmanaged dll, or does Windows keep one copy of the dll and maintain a usage count? If the latter is is the case, how do we get each instance of the unmanaged dll to reflect its unique configuration?
I think unmanaged dlls are loaded only once per process by the OS, so every app-domain will have the same loaded instance. To unload a dll, use the FreeLibrary function. However, since multiple app-domains are likely to have loaded the dll, there is no guarantee that FreeLibrary from one app-domain will actually free/unload the dll.
As BillW says, this seems like a design nightmare to me too!