I'm using Visual Studio to create C# application which uses SQLite database.
What I want to do is save DLL file in subfolder named 'config'. I've created config folder inside bin/debug folder and copied System.Data.SQLite.dll file into it.
Then I added Reference to my solution using bin/debug/config/Systtem.Data.SQLite.dll file.
The problem is that every time I build solution VS creates new System.Data.SQLite.dll file directly inside bin/debug and when I try to use my application (after deleting bin/debug/System.Data.SQLite.dll) it throws an exception = it cannot load dll from inside config folder...
How can I solve it?
You ought to use the default behavior of loading from the EXE's directory.
If you really don't want to, set Copy Local to false on the reference and load the DLL yourself by calling Assembly.Load.
Note that you'll need to load the DLL before calling any methods that use its types so that the DLL is already loaded when the runtime JITs the methods.
Here's some more info on the topic: http://msdn.microsoft.com/en-us/library/4191fzwb.aspx
Related
I have several Visual Studio solutions/projects (some VB, some C#) that all reference a common DLL at design time. This DLL does not have to be copied to the output folder as it is only needed while writing code. Every few months this DLL will be updated to a newer version and all of my projects need to reference the updated version.
What is the best way to handle this?
You have to use a Shared Assembly, shared in GAC (Global Assembly Cache).
Say, you have programmed a class, a piece of software, whatever you have, and you want to make it a shared assembly.
First you make it an assembly by creating a new Class Library Project in VS and transporting all of the code to that project. Don’t build/run it yet! Note that we just transport the code but the assembly (the .DLL file) is not actually made yet, because we have not built the project yet.
Before building the assembly, we have to create/share a key by which the assembly is known, in 2 steps:
a) create the key by executing the cmd below in VS cmd:
sn -k "C:[DirectoryToPlaceKey][KeyName].key" b) share it by adding the attribute below to the AsseblyInfo.vb/cs file in the properties folder of your Class Library project:
In VB.Net:
In C#:
[Assembly: AssemblyKeyFile("C:[directory containing the key file][KeyName].key")] (just copy and paste this into the AssemblyInfo.vb/cs file, but write your directory and file name instead).
Now, you MAKE the assembly by building the project. Just build the project (just press F5 once, at least!). By doing so, the .dll file we need (the assembly) is created in the “bin” folder in the same folder of the project.
Now we share it by Copying the .dll file into the GAC (Global Assembly Cache: it’s where all the assemblies are gathered together. The directory is: “C:\windows\Microsoft.Net\assembly\GAC_MSIL” but you don’t need to know that since the tool below does that for you~) by executing the command below in the VS cmd:
gacutil -I "C:[PathToBinDirectoryInVSProject]\myGAC.dll"
YOU'RE DONE! You may now reference and use the shared assembly from all your applications, and whenever you want to update, just update the shared assembly.
Hope that helps!
You can create nuget resources, and use Nuget Server (Lastest version of teamcity support it) - and all updates w'll be handled by nuget.
Other approach is to create common folder and all project point's to dll in this folder (relativly) in this case you need to udate dll in one folder (after rebuild solution dll'll be updated automaticly)
Ofcourse you can allways install dll in GAC (Global Assembly Cache) this is handled by tool called gacutil.exe (in net is lot of example how to handle it).
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.
I have a dependency folder that I use for dll's in my web application. Some are referenced in the web application, others aren't. However for the application to run I need to have all the dll's in the bin directory of the web application. But I dont want to reference them in the web app. Is there a work around for this? I was considering the post build event to copy in the dll's required from dependencies to bin directory.
If the assemblies are implicitly referenced (required by assemblies you have referenced) they should be automatically copied to the output path. If there are assemblies which you are dynamically loading with reflection like form example some plugins you will need to copy them manually to the bin folder. A post-buid event seems like a good approach.
You can use PostBuild event as you mentioned or edit the project file to include MSBuild Copy Task.
Check: http://msdn.microsoft.com/en-us/library/3e54c37h.aspx
To be short and to the point, I've built a C# class library that is both COM-Visible and Registered for COM Interop. I've compiled the library, which resulted in the generation of .dll and .tlb files.
I have another machine that's running a VB6 application. So, I copied the .dll and .tlb files over to C:/Windows/system32 folder on the machine. I then registered those files using the following:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm C:\Windows\system32\TestClass.dll /tlb:TestClass.tlb
After the files were registered successfully, I added a project reference to the Test.tlb file from inside my VB6 app, then I tried to invoke a method in my new referenced class like so:
Dim myObject As TestNamespace.TestClass
Set myObject = New TestNamespace.TestClass
MsgBox (myObject.TestMethod())
It doesn't work, and I receive a -2147024894 Automation Error.
I've read that I shouldn't install the dll into a private folder like system32. I should either be registering in the GAC or I should be registering in another location using the "/codebase" option:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm C:\TestClass.dll /tlb:TestClass.tlb /codebase
Is there any reason I shouldn't be using system32? Past devs that have worked on this project have placed assembly files used by this VB6 project into system32 and there haven't seemed to be any issues.
When I register my dll in the system32 location, I get the Automation Error. When I register my dll in another location (i.e. C:/), the method call into my class library from VB6 works as expected. What gives?
I should mention that we will NOT be using the GAC to register any DLL's. That's just the way it is.
Any help is appreciated.
Mike
I haven't had any problems with using regasm for a dll in system32. I always use the /Codebase switch, which puts the location of the tlb in the registry so VB6 won't get confused.
See the MSDN page for more info.
I'm writing some extension and I need to pull out data from the file that is included into vsix. But if I'll use Environment.CurrentDirectory I will not have this file because this folder points to VS folder not on the extension's one. How can I define it in a run-time?
System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase get the path to the executing dll.