I wrote a program in VB.NET which uses several .dlls that I programed in c++. The dlls wrap some functions from an old version of the program. On my development computer everything works fine but I build a release version, copy it and the dlls onto the target machine and the .exe starts up fine. When the program tries to use a function from the .dll it throws an exception and says "unable to load DLL "c:/the path/my.dll" the specified module can't be found."
I don't know if it makes any difference, but I am defining the dll functions in the main vb project using:
Declare Function MyFunction Lib "c:/the path/my.dll" (ByVal in1 as Double, ByRef out1 as Double) as Integer
I have checked the .net framework on the target and version 4 seems to be installed same as the development computer. Both are windows XP machines. I have no idea if it is the way I programmed the .dlls or just something with my vb.net project. Any help is appreciated.
Use a path relative to your executable, rather than an absolute path.
Or, even better, don't use the path at all and just list the name of the dll file. Then add the dlls as resources to your project. You should then be able to easily bundle the inside your setup project and they'll automatically end up in the right place for both debugging and deployment.
If I am not mistaken, you want your application to function with all the .dll files you used and worked on your machine. The simplest thing to do is to publish your Program or application. But first, you have to follow the following steps in order to include all the .dll files that you want your published program to use.
Click the Project tab and select the Add References… menu.
from the opened new window, use the Browse… tab to locate the files you want to add to your project, then click Add.
Then from the project menu, select your project property: for example, if your project is named Johns_App, then in the project tab, you will find Johns_App Properties. Click this, and it will take you to a new window.
In this new window, click the Publish tab, then from the Application Files… tab, you can check, include, and exclude the project files. Then you are all set.
I suggest using the Publish Wizard…, as it will guide you step by step.
Hope this helps
Found a link to a CodeProject page which referenced this same problem.
Basically you need to check that all dependencies of the DLL file(s) are available in the running location. Using the Microsoft Dependency Walker led me to the solution that one of the dll files used in my VB application was referencing a different dll file. After placing that other DLL with other run files no more error!
Related
I have been working on a few different applications and I want them all to share the same DLL library. The shared DLL is one that I created, so really I want each application to have a dependency on the DLL so that the DLL gets built in the same solution as the application. Then the DLL should copy itself to the application's bin folder before the application runs.
After figuring out how to do this, it seems that it should have only taken about 5 minutes, but unfortunately it took me an hour to figure out. That's partly because similar questions were referring to older versions of Visual Studio, or referring to 3rd party DLLs. So I thought I'd post the steps here.
You should already have one existing project and solution for your DLL. Open your solution for your new application that depends on your DLL
Highlight the top line in your Solution Explorer (your solution name), then go to the File menu and choose Add > Existing Project...
Browse to the project file for your DLL and select it. That will add the DLL project to your solution
Although your projects are now in the same solution, that didn't actually create a reference for your main project. So now right-click on your original project (should be 2nd line in your Solution Explorer) and choose Add > Reference...
The Reference Manager will appear. Be sure that you have Solution > Projects selected on the left. Then you should see your DLL project listed on the right. When you hover over it, a checkbox will appear. Select the check box. Click OK.
Last, be sure that your Project Dependencies are set correctly. Again, right-click on your Solution in Solution Explorer (top line). Choose Project Dependencies...
In the Projects drop down, make sure your main project is selected. Then in the Depends On list below, check the box for your DLL project.
Now when you Build your solution, it will first build the DLL, then copy it to your applications bin folder, then build your application. The Reference will also allow you to refer to the DLL in your code files, for example with "using MyLib;" for C#, or "Imports MyLib" for VB
Now when you Build your solution, it will first build the DLL, then copy it to your applications bin folder, then build your application.
Thank you for explaining this. I did all the steps (Visual Studio 2015) and I noticed that "Build solution" command builds all the DLLs, but it does not copy them to the right bin folder. To achieve that I need to build the active project (right-click on the active project, then "Build").
I've written a Windows program using the C API of Tcl/Tk to create a nice GUI. I've installed ActiveState ActiveTcl for the dependencies and everything compiles and runs fine. Compiling required me to link against the import libraries provided by ActiveTcl.
Now that i want to distribute this program i have to make a choice on how to handle the dependency on ActiveTcl. One option is to require ActiveTcl be installed before my program, while another is to just distribute the ActiveTcl DLL's that my program actually uses.
If i view my program using a Dependency Walker i can see that three ActiveTcl DLL's are used. tcl86.dll, tk86.dll and zlib1.dll. So then i tried to move the DLL's.
If i moved these DLL's to the C:\Windows folder or to the program's folder, the program no longer functions. After moving the DLL's and viewing the program in the dependency walker, i can see the DLL's are being found in these alternative locations but the program refuses to start. I don't even get an error.
Do any of you guys know why this might be the case? That the only time my program runs is if the DLL's are located in the installation directory of ActiveTcl (C:\Tcl\bin).
The DDL's had dependencies of other files that should exist in the same folder.
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.
i am try to develop a small application.
Now should i organize my 3rd party dll libraries so that when i publish the project and than install that application on another computer all the libraries should move with installer...
That's what the bin folder is for. Just an FYI though, I've noticed DLLs not ending up there before and I'm like what did I do wrong?
Expand References in the Solution Explorer
Right-Click on your DLL and select properties
Make sure it says "Copy Local", I had one that wasn't showing up and it said false.
i added itextsharp.dll to my project. it is on my desktop. everything compiles and works fine. if i install my application on another computer it is looking for the same file itextsharp.dll on the users desktop.
how do i make it so that the DLL is built in to the project??
What's with the Desktop now?!
Bundle all your deployable assemblies in the same output folder as your application's main assembly.
While creating the Setup...I am assuming your using MS project setup..make sure all the deployables point to a common folder target.
I don't understand your fixation with Desktop...pls let me know if that is some sort of requirement.
The only thing that is usually deployed onto Desktop is the App's Shortcut.
Make sure that when you add the DLL to your project, you set 'Copy Local' to true. That way, the DLL will get copied to the 'bin' folder of your application rather than the original location of the DLL.