how acually DLL concept works for vb.net project
I have included Microsoft.office.interop.excel dll and sqlite dll
but in other PC, excel dll gets automatically installed with setup
while sqlite dll, I need to manually put in GAC
why it is so ??
any solution, so that I can avoid manual work of copying...
You could provide an installer/setup with your application to install the assemblies in the GAC. Or just provide all the assemblies in the same directory as your application. If the assemblies are not yours, then please check if and how you can redistribute it.
Related
I am am considering installing a dll assembly in the GAC and I don't have enough experience to know if this is the best practice for this scenario. Hopefully someone here can shed some light on me and get me pointed in the right direction.
The Scenario:
I have a library assembly that I have written. This DLL is designed to read some data from an output file of a third party software package. Once read the data is available for access to the caller of this DLL.
My company has developed four different windows form applications that use this library file to get data into the apps.
The 3rd party software manufacture has change the the way they write their output file, so I have modified my DLL to support the new features the third party is using.
Currently all the apps have been written using the dll as a private assembly.
The Update:
To update all of the applications would require a rebuild of all four apps referencing the updated dll file, then reinstall all four apps on every machine that may be running them.
If I were to change the dll to a GAC assembly, then all I would have to do is reinstall the updated dll in the GAC assemble on every machine that uses the DLL assembly.
The later option seems to be simpler, then the next time this happens, we just update the one dll in the GAC and away we go.
The Question
What is the best practice here?
This link makes me think I should not be thinking about GAC
When should I deploy my assemblies into the GAC?
And if GAC is the answer how do you go about deploying the strong named assembly so that is installed in the GAC from the setup file?
Any help is appreciated,
Mike
Is there any way in VB.NET to DllImport a dll file from the resources?
I really don't want to add the dll with the executable path.
You can embed a DLL into an executable:
Jeffrey Richter: Excerpt #2 from CLR via C#, Third Edition
Many applications consist of an EXE file that depends on many DLL
files. When deploying this application, all the files must be
deployed. However, there is a technique that you can use to deploy
just a single EXE file. First, identify all the DLL files that your
EXE file depends on that do not ship as part of the Microsoft .NET
Framework itself. Then add these DLLs to your Visual Studio project.
For each DLL file you add, display its properties and change its
“Build Action” to “Embedded Resource.” This causes the C# compiler to
embed the DLL file(s) into your EXE file, and you can deploy this one
EXE file.
At runtime, the CLR won’t be able to find the dependent DLL
assemblies, which is a problem. To fix this, when your application
initializes, register a callback method with the AppDomain’s
ResolveAssembly event.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I have already built a project, and run it in VS2010.
But if I want to run the .exe on other computers which does not
install Visual Studio, it will need .dll files (such as msvcrt.dll and
msvcp60.dll in WINDOWS\SYSTEM32, and some other dlls in the
development package). I didn't use MFC in this project. How to static
link all these dlls into the .exe file in Visual C++ so that I don't
have to copy all the dlls to the other machines?
BTW: I don't want to make install package either
Thanks
Siba
You can set your project to statically link the CRT, by using the /MT flag for the runtime library. Or, you could keep the /MD setting, and install the vcredist package along with your executable (you can get it from here, and also from one of your VS2010 installation folders). To get an idea of each options pros and cons, read this.
Oh, and a similar question has been asked before...
In an attempt to keep my build machine clean can .local files be used during the compile of an application or is there a better way to keep the bloat off the machine.
.local is used to force Windows to use the COM DLLs in the VB6 application directory in preference to the most recent version stored in the registry. It doesn't replace the necessity of registering the DLL as Windows need to look in the registry for the CLSIDs of the older version.
Registry free COM DLLs is explained here and involves the creation of a manifest file. Similar in principle to what .NET goes through with it's assemblies except .NET handles this issue automatically and with ActiveX DLL it is more of a manual process.