I am writing a commercial application in VB.Net using VS2010. My application needs to access a MySQL database. So I have a reference to MySQL.Data.dll in the "References" section of my Project. For licensing reasons, I want to make sure that this dll file is not embedded in my application. From what I read, if I set the "copy local" property to False, then the file is not copied and I need to specifically copy it to my bin directory. So I set it to False and built my project. When I run it, I can still connect to the MySQL database even though the dll is not in the bin directory. To me this indicates that it is being compiled with the build. However, the reference points to a location on my hard drive where the original MySQL.data.dll resides. Could it still find it there when the program is run?
How can I make sure it is not getting compiled? Thanks.
By the way, it is not in the GAC (I checked using gacutil.exe)
If you're referring to having the actual assembly embedded into yours, then no it does not. It can be done, but it does not happen out of the box.
The application looks at many places for your references when it needs to load it.
GAC
Next to the application (maybe also the consuming assembly)
x64 and x86 folders next to the application (maybe also the consuming assembly)
Any paths specified in the app.config/web.config for the referenced assembly.
Keep in mind that just because your application fired up, it doesn't mean it found all of the references. It more than likely hasn't loaded all of them yet as it will only do it once it is needed.
Related
I am using JSON.Net to get my Console application to translate sentences with Google Translate. My code fully works fine with absolutely no errors when I run it in Visual Studio. But when I take the .exe out of the "[project_name]\bin\debug" folder and copy it to the desktop to run it returns the following exeception.
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified....
I noticed that in my "[project_name]\bin\debug" folder there is the .dll file that I am using, but not only this, I am also using a .dll that I referenced somewhere else.
When I drag this .dll file with the exe onto the desktop and run it, it works. How do I make it so that I don't need the .dll with the .exe on the desktop? Or is this something that is necessary? I am sure that I have referenced everything properly.
If your application makes use of a library then that library has to be there to make use of. There are basically two ways to make libraries available to .NET applications. The library needs to either be in the same folder as the application or it needs to be installed in the GAC (Global Assembly Cache). The GAC is a common location for libraries so that multiple applications can access them. Unless you intend to ensure that JSON.NET is installed in the GAC on every machine you plan to run your app on, you need to make sure that the library is deployed along with your app. This is how applications work. There is no magic solution.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I have done extensive testing with this and have isolated the problem to this. I'm trying to keep this to the point but please ask if there's any other information you feel I'm leaving out.
-a.exe is our vb6 app that references x.dll
-x.dll is an in house vb6 dll that references y.dll
-y.dll is an in house .net interop dll
-Everything works fine on the development machines.
-I have more than triple checked our .net setup project to ensure files are being pulled from the correct places.
When installed, a call from x.dll to y.dll fails. Ultimately how I am able to fix this is by copying x.dll from the development machine over the x.dll file that was installed by the setup project on the target machine. These two should be identical.
Anyone have any clues whatsoever what this could be? It's pretty much the strangest dll problem I think I've ever had :(
Though I fixed the problem, I still don't completely understand why there was a problem but here's what I found...
Vb6 always wants to change the dll being referenced to the one most recently registered. We used to register dlls to an application directory located in C:\ and not within the source code folders, and we referenced them from there, and grabbed them from that directory for the install package.
When we switched to subversion we moved the dlls into a dependency folder within the branch. However, the dlls continued getting copied and registered to the application directory as well where the build would grab them from. I had to update the build to grab the dlls from the new branch location and stop them from being copied to the old location.
That seems to have fixed the problem, but I don't fully know why because a comparison of the dlls in both locations showed they were identical.
In our environment, we have two in-house frameworks and a separate website. During development, the references to the in-house frameworks tend to be set tp project references. However, once we move to release, the in-house frameworks are installed into the GAC as they are used for multiple instances of the website on each server. All of the ProjectReferences are changed, by hand, to References and the website assemblies and website are re-compiled and deployed.
I am attempting to automate this process. What is the best way to handle these issues? I have started to learn MsBuild in the attempt to accomplish this, but am totally confused. Any pointers and/or suggestions on how to proceed?
As far as I am aware there shouldn't be any need to change from using project references to file references simply because the assembly is registered in the GAC - as long as the referenced project is strongly typed at the point that it is built, the reference should still be valid.
Clarification:
There is no fundamental difference between a GAC reference and a file reference - if you have a reference to a strongly named assembly, and that assembly is placed in the GAC then the end application will load that assembly from the GAC.
See this link for more information on how the runtime locates referenced assemblies:
http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx
FYI - I believe it is recommended that you don't reference assemblies which are in physically in the GAC, and that you instead reference the strongly named assembly before it is placed in the GAC (not to be confused with whether or not the assembly should be installed to the GAC on the end-user machine)
If you leave the project references in, MSBUILD will copy all the project references as DLLs into the target website's bin directory, even though you've installed these DLLs into the GAC, which I assume is why you want to change this at the release level--so that space can be saved.
I also assume that you are intending to do this at the Release Branch only, and not at the development branch of your source control. Because if you are doing this at all branches of source control, then doing by hand is actually the best and fastest way of doing this for a one-time change.
To do this in MSBUILD, you will need to create a custom task that can modify the project file. The project file is an XML file, so you could use XPath as your custom task in MSBUILD. In the project file, you will find tags for "" to your referenced projects. You will need to change those to "" tags instead. Use existing examples of the tag in your project to see how it should look
Sorry I don't have sample code for this--doing it this way will be a bit of an undertaking, as there will be a number of things to take into consideration, and it might end up not being feasible.
VB.NET: Can the .EXE built by VS2005 be deployed as a standalone EXE?
When I change the mode in VS2005 to "Release" and build the solution, the bin\Release directory then contains the solution .EXE file, but also a .pdb, vshost.exe and .xml file. What are these extra files and are they necessary?
I copied the .exe file to another machine and it executed properly, but there was a significant delay when it first executed - thereafter it was like any other program. What is the reason for this, and can it be helped? Is it because the other 3 files in the Release folder are not there with it?
The project template that you used to get the project started doesn't have very optimum settings. You'll get the clutter as a result. It is easily fixable. Start with Project + Properties, Compile tab. Make sure the Release build is selected, upper left combo box labeled Configuration.
The .pdb file contains debugging symbols. You don't need it for the Release build although you get slightly more informative exception messages. The stack trace will contain line numbers. You cannot trust them for a Release build though. Click Advanced Compile Options, Generate debug info = None.
The .xml file contains IntelliSense info, it will be generated when you use XML Documentation in your source code. Meant to be used for assemblies that are referenced in another project, quite pointless for an EXE project. Turn off the "Generate XML documentation file" option on the Compile tab.
The .vshost.exe file is a helper process for debugging your app. It hosts a custom version of CLR, configured differently to help with security issues while debugging. It also makes the output of Console.WriteLine() appear in the Visual Studio Output window. There's little point in having it created for the Release build. Select the Debug tab and uncheck the "Enable the Visual Studio hosting process" option.
After making these changes and rebuilding, you should only have the .exe file left in the bin\Release folder.
The slow startup is what's called a "cold start" of the .NET framework assemblies. It is caused by a slow or fragmented hard drive. Since the DLLs were never loaded before, the disk drive needs to dig through the GAC to find the files. You can probably improve it by defragging the disk. Cold starts are never as fast as warm starts though.
A classic trick, used by Microsoft Office and Adobe Acrobat, is to warm up the file system cache by loading their DLLs at login time. They are called "optimizer" in the Startup folder or Run registry key. Very annoying btw, they slow down other programs. You can do the same thing by writing your own little .NET program that doesn't do anything but create a few classes. Put a shortcut to it in the Startup folder.
You should be able to just ship the EXE. The PDB and VSHOST files are used for debugging, you should be able to configure your Release build to not generate these files. You can set this in the 'Advanced Compiler Settings' dialog from the Compile tab in your project properties.
alt text http://philippursglove.com/stackoverflow/compilerdebugoptions.png
(Hat-tip to Amissisco for pointing out it's the same dialog in VS2005/2008.)
I'd imagine the 'significant delay' you experienced when running the program for the first time was due to the .NET Framework being loaded into memory (and probably then paged back out to disk) - unfortunately there's not much getting round that one. You could try throwing hardware at it - memory and a solid-state disk would probably give an appreciable speed increase but may not be a cost-effective option if your application is going to be released on a significant number of PCs. However this should only take place the first time you fire up the application after a machine restart, which is why subsequent launches of your application are quicker.
Only .Exe file is required for deployment. But its better to create a setup. If you are using App.Config file / Application settings, you need to copy the exename.config file too.
Yes, you can deploy it as a standalone EXE, together with any third party DLLs that do not belong to the .NET Framework as well as other resources such as application.config. images and/or other media assets.
The .pdb contains additional symbolic debug info which is not necessary for your application to run. It's meant to assist debugging so that you see your source code instead of assembly code in the debugger.
vshost.exe is used by Visual Studio only, not too sure about the exact purpose of it though.
Whether these three files (.pdb, vshost.exe and the .xml) are present with the .exe should not affect the loading speed of your application. As .NET applications have to be compiled upon first run, the delay that you're experiencing should be partially due to that.