I have been struggling to find solution to prevent application from searching .dll files in program installation directory.
I have tried many approaches like SetDllDirectory, delaying .dll loading etc.
However my tests shows that .dlls is still searched from installation directory and only then C:/Windows
I have tested it by adding one of my own .dll that runs cmd. For example if I place DWrite.dll in installation directory in always runs cmd and then runs application.
I have few projects with same issue, one is pure C++ and other is C#, that uses some of C++ sub projects in it, this makes it even more difficult to solve.
Do anyone know proper solution for this or workaround?
Related
I'm new to c#, and i'm stunned by the amount of files that are generated by my release output.
I wrote a REALLY simple program that i want to distribute, no external assets or anything special.
but still, there are 10-15 files generated (.dlls, .pdbs, .configs, etc. etc.)
I did a little research yesterday and i got the impression that it is simply not possible to clean up this mess without a REALLY big hassle?
i tried Fody (didn't work at all) and Tidybin (or something like that?) (created a lib folder and put everything there, which was nice, but the program stopped working and threw errors about the missing files)
I'm looking for a way to generate a clean release version.
ideally with JUST my exe, with all the dlls and other stuff embedded, but everything i read about that was just way above my head and overly complicated (why isn't this super easy to do???)
if that's not possible, i'd be happy with moving everything except the .exe in a lib folder. but that didn't seem to work. how do i update the path inside my application, so that those files can still be found? like i said, that plugin seemed to do half the job, while leaving all links like they were.
(side note: why is there not ANY KIND of ducomentation for all of these plugins? i really don't have the SLIGHTEST idea what to do)
thanks
If you have a simple application, there shouldn't really be that much in the folder.
Actually, there should be:
1 exe, 1 pdb (only for debug build), 1 exe.config file for the application
1 exe, 1 pdb (only for debug build), 1 exe.config file for the Visual Studio Host Process
If there is the System.Net.Http library referenced, this could create a folder with many localizations. If you don't use it: Remove the reference.
Please note that you do not need to deploy all these files! If the application only references framework DLLs, all you need is the .exe and .exe.config file.
DLLs will not be embedded, but if they are framework libraries, they should not be added to the output folder unless you set the "Copy Local" property of the reference. And you don't need to deploy them along with your application, as obviously they are installed along with the .NET framework on the target system anyway.
If you reference any DLLs that do not belong to the .NET Framework, you normally deploy them along with your application. It's easiest to put them in the folder along with your application, but you can also put them in the global assembly cache on the target system.
There are solutions that package the executable, third party DLLs and stuff into an EXE wrapper that is unpacked every time you start the application, but I advise against this. The user won't expect this to happen, virus scanners may block this and builtin mechanisms like .NET settings may not work properly for those solutions.
The easiest way to distribute your code is using InstallShield Visual Studio edition. (That is available with your Visual Studio license)
Download and register, then add a new distribution project to your solution.
InstallShield Limited Edition for Visual Studio
A wizard will help you by selecting the main distribution files. And it is a useful tool distributing new releases of your application.
As a second option I use is ClickOnce (Microsoft), but for specific internal applications.
ClickOnce Deployement
I am very new to the .NET framework, and have been stuck on this issue for a week now.
I've been given a C# codebase, that is composed of several sub-projects which make use of DLLs compiled in C++. Each of these projects are inter-related, as they reference each other (non-circular).
If I create a basic Windows Forms Application, I can call functions from these DLLs no problem, by adding a reference to one of these sub-projects. However, if I create a very basic ASP.NET web app (which builds and runs fine on its own), it will break as soon as I add a reference to the sub-project I need.
By breaking, I mean I am given this error:
Could not load file or assembly 'XXXXX.DLL' or one of its
dependencies. The specified module could not be found.
I have done a lot of reading on this, since it seems to be a fairly common error, but none of the attempted solutions have worked.
To generalize, my main question is: Given two projects (one a windows form C# application, and the other an ASP.NET web application), both located in the same directory referencing the same project/DLLS, why does the web application struggle in locating the proper DLLs and/or dependencies?
Thanks in advance!
In the .NET application, have you tried compiling the DLL's and copying them directly into your /bin directory? That way you're eliminating the dependency and any reference issues VS may be choking on.
Then be sure to remove the references from your project so it's only using what it finds directly in the /bin directory. See if that works for you.
Once you're sure the issue is truly the references vs the DLL's themselves, and you project builds completely, try adding the references back in....be sure to do a clean of the project, then a rebuild.
If that still doesn't work, make sure both projects are not in the same solution. I had this issue not too long ago and it only seemed to work when I removed the other projects from the solution, opened another instance of VS2015 and then I was able to get everything working.
I know, I know....not really an answer if that ends up working, but when it comes to Microsoft's products sometimes we need to get a little creative. Let me know if this helps.
Several weeks ago I have build a Native C++ .dll that wraps a third-party .dll to be used with C# P/Invoke in several applications to be deployed in WES7. I've been using Windows 10 as a dev box and everything works as expected. This week I finally got my hands on the box with embedded Windows and things are not doing that well anymore... I've tried to deploy three different C# applications that use the .dll I built alongside the third-party one but they all fail with a DllNotFoundException. Obviously both .dll files are in the same folder as my executable file for each project, but I keep getting the DllNotFoundException. My native .dll targets the Win32 platform, the embbedded windows is a 32-bit system, and all my C# apps are built to target the x86 architecture, so I've ruled that out. I've wasted the last hour messing around with the system32 folder to no avail, so I've run out of options. Any suggestions will be appreciated.
Edit: I just talked to a co-worker who works remotely and he had the exact same problem when trying to run our .dll under WES7. I'll update this question as soon as I have more info.
In the end, I happened to be dumb enough to deploy a DEBUG version in the target machine, which didn't have msvcp100d.dll and msvcr100d.dll. I used Dependency Walker to figure that out (apparently it was too hard for me to take a look at the project properties page drop-down) and deployed a release version in the target. It finally worked, but I had a different problem that leads to another question...
I'm coding a simple application that I need to be portable (the user can just run it by clicking on the .exe without having to run a installer).
All the other questions on this subject that I found on StackOverflow wants to make .NET Framework "bundable" with the software, but I don't need that.
A workaround that I found is going to /bin/Debug on the project folder and use the .exe there, but that seems "wrong". Is there another way to make a software written in C# portable?
Thanks!
EDIT: Okay, I'm really dumb and I asked all the wrong questions. However, your answers pointed me to the right direction. I wanted to know how to generate the .exe to send to my friends. What I had to do is change this to "Release" and press F6. I added this so if someone with the same "doubts" that I had can find the answer easly. Thanks!
Going to bin/Debug and using the DLL there is wrong.
Instead, build and copy the one from bin/Release.
If there's anything else inside the folder, though (except *.pdb), then beware. Your application might need those additional files. For example, the app.config.
All .NET applications are "portable" as long as the machine you are running it on has the version of .NET you are targeting (or a compatible version). The key here is to make sure that your application does not depend on things that an installer would take care of for you to make your application work. Examples include: registered DLLs (like Interop assemblies), registry keys, or components that must be found in certain locations (such as having something stored in user's AppData folder).
As long as the machine you want to run it on has .NET framework, you can make any .NET application portable. If the app you're making has no dependencies other than .NET then it's fully portable already. Even if it does have dependencies just include those with the executable.
To expand on Zerkms's comment:
Every software is portable by default. Installers are a way of telling to program to search for resources in a certain place, meaning that if the place isn't there, eg: C:\Windows then the program won't be able to run.
So as long as you have the application have the resources already within the exe or a root folder search (so where the program is, rather then where it should be) then you'll be fine.
If you're using default controls, it should be fine as long as your software's running framework version is installed on the computer. If you're using 3rd party controls, you can emded the dll's into the .exe upon compiling. Do note that the more dll's you embed, the bigger the .exe file will be.
In VS, I've only tested code and debugged it, but never actually prepared anything for a finalized program or release. Some of the programs I've downloaded have had dlls that need to be in the folder they're in, and I've had programs that come as just one .exe. Is there a way to compile all the files into one application and not have external dlls? Is this bad programming practice for some reason? How do I compile my VS program into one executable file?
I know this is quite an obvious question, which is why I can't really find an answer, because it would be too obvious to write any kind of tutorial on it.
With a managed language like C# or VB.NET, ILMerge is a utility that you can use.
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output.
If the question is just around getting VisualStudio to build executable programs, it does it every time you run them within it. If you are using all of the default settings, open your project folder and look for a /bin directory. Underneath it, there is a /debug and a /release directory. If you build your program in debug mode, look in the /debug directory, if you build it in release mode, look in the release directory. VS will put everything that your program needs within that directory. You can copy all of those files to another machine that has the .Net runtime installed and it should run.
If the question is more about combining multiple dlls into a single exe, actually, there is a tutorial on it at CodePlex:
As you know, traditional linking of object code is no longer necessary
in .NET. A .NET program will usually consist of multiple parts. A
typical .NET application consists of an executable assembly, a few
assemblies in the program directory, and a few assemblies in the
global assembly cache. When the program is run, the runtime combines
all these parts to a program. Linking at compile time is no longer
necessary.
But sometimes, it is nevertheless useful to combine all parts a
program needs to execute into a single assembly. For example, you
might want to simplify the deployment of your application by combining
the program, all required libraries, and all resources, into a single
.exe file.
http://www.codeproject.com/KB/dotnet/mergingassemblies.aspx
Lastly, if the question is about building an installer for broad distribution, Jan Willem B has a sample for WIX: Using WIX to create an installer: quickstart tutorial
Yes, you can use ILMerge for embedding managed .Net DLLs! Example here.