Title
I am pretty new to C# (although I'm coming from java so I'm catching up quickly) and when using Visual Studio and building, I get a bunch of files as well as the executable, including dlls with the names of a few of the nuget packages I installed, a dll, pdb, etc. I also realized that I can't just give out the .exe from that folder because it references the files surrounding it. I want to put all of these files into one final executable that uses the needed files without installing them. Also, my project uses Tor and the only thing I need help with there is being able to package my project with tor as well (again, preferably in the same executable so that the user doesn't have to have tor installed to use my program.
TL;DR/summary: how do I include all the required dlls in 1 final .exe that will also be able to hold another exe (tor) inside it so that tor doesn't have to be installed for it to work?
I guess I could download the tor expert bundle when the application is launched but again it would be nice if this wasnt needed
I found an answer that I guess will work for now: How to merge multiple .NET Core assemblies into a single one (.dll / .exe)?
This still doesnt fix the problem of trying to keep tor inside the executable, but I guess I am just going to have tor download into some temp folder until I find a better fix.
use .net core 5.0 . Use with Ilmerge nuget manager.
Related
I have two separate projects/solutions. One is an ASP.NET web app and the other is a console app that runs as a WebJob on Azure. These two separate projects/solutions share some common projects' DLLs.
We work on these shared projects through the web project's solution in Visual Studio and when done, I copy and paste the DLL's into the bin folder of the console app.
When I compile the console app, I notice that the shared DLL's revert back to a previous version. I know this because I see the Date Modified dates of those shared DLL's. The moment I compile the console app, they go back to previous versions.
Why is this happening and how do I prevent it?
You definitely should not drop assemblies into output folder by hand as they will be overwritten from whatever location build takes them from. If you have to do it manually - copy files over original location. To debug - enable verbose logging for build and carefully check where assemblies are copied from.
Automated solution integrated with the build is better approach.
Standard solution for sharing assemblies between project is NuGet. As most basic solution you can just use file share to drop packages. Check out guidance for continuous integration build system you are using as there is probably recommended nuget source (i.e. package feed in VSTS).
I am trying to create a program, allowing silent installation of important updates for Windows. I want it to be a single .exe file, without any additional files, libraries, icons etc. I am using .Net 3.5. I included wuapi.dll to the References folder of my project. After compilation wuapi.dll is copied to the same folder, where goes .exe file (Debug or Release).
I've read different articles about usage of ILMerge for embedding .dll files directly into .exe file. And here is my question - all the Windows computers have wuapi.dll in system32 or SysWow64 folders, so why should I embed it into my project? Is there a way to make a reference to these libraries or use their functions without adding them to project at all?
On the References, select the wuapi and set the property CopyLocal to false. Also, make sure that the SpecificVersion is set to false, otherways it may not work with whatever version is installed on the user machine.
I would assume that wuapi can be found in any Windows version since XP.
This only works on .Net 4.0 on by setting "Embed Interop Types" to true. On .Net 3.5 you don't need to deploy the wuapi.dll itself but you need to deploy the generated Interop file.
For more info check: http://blogs.clariusconsulting.net/kzu/check-your-embed-interop-types-flag-when-doing-visual-studio-extensibility-work/
I'm re-doing an old .NET 2.0 app in WPF4 and C#. I don't have the ability to to use an installer with this app. With the old version, all I had to do was copy a single .exe file. But with the WPF app I see I need more than that. But how much more? I can copy the DLL's over one at a time till it runs, but I don't feel safe doing it this way. So how can I know what folders (I see several language folders) and files I truly need?
My end goal is to only need to still use a single executable file. I will either add the needed DLL files as embedded resources, or use ILMerge. The smaller number of files I need to do this with the better.
PS. I can't use an installer as a condition of my employer. My app is meant as a tool to assist our techs on support calls. The fact that it uses .NET was met with resistance so I'll comply with the rules.
Thanks
Apart from dependencies on the machine itself (.net framework 4 for example) you'll only need what's in the project's output folder, by default bin/Debug.
We have an Entity Framework project with several models set up using .NET 4 and VS2010. Then we have several projects that need to use this entity project. We successfully compiled the EF project into a DLL. We have also successfully added the EF dll reference into multiple projects which is working great.
The problem is now that we have several programs (ASP.NET and console apps) that reference this EF dll and the dll is copied locally for each calling program, when we make a change to the EF dll, we then have to go into each and every project and replace the EF dll with the new build.
I've done a lot of searching for sharing libraries and even EF projects across multiple projects. While I have found several, I can't seem to find a good example that I can make work for my situation or that isn't so old that it's irrelevant.
That is the general issue I'm having. To give a better idea of the issues I'm encountering, I will focus on one particular project. This is an ASP.NET webform project for in intranet. If we add the EF dll reference and allow the project to copy the dll locally, the EF works fantastically. However, because we have multiple project we now need to try and centralize the EF dll somewhere where it can be shared by the multiple processes. I am not trying to set this up so that one EF dll is accessed across multiple server. I am happy to install a copy of the DLL on individual servers if necessary.
My desire is to create a "common libraries" directory on each server, simplified example "C:\OurLibraries". We would then put or EF dlls (and maybe others later) into this folder and allow the various programs/processes to access the common copy of the EF dll. I've made sure the "local copy" of the EF dll has been removed from the intranet project and added a reference to the "C:\OurLibraries\OurEF.dll" file. Everything builds fine and the intranet project works fine until it tries to display a page that has references the EF and then displays an error message:
"Could not load type 'EntityNS.ProductDBEntity'."
If I turn on "local copy" in the reference, the intranet site works fine again. I cannot seem to find that magic setting that will allow me to share the EF dll.
I have tried the following things based on various posts, but with no success:
Signing the assembly and adding to the GAC. Experienced the same issue as having it in "C:\OurLibraries"
Adding the "C:\OurLibraries" directory to the PATH environment variable.
Changed my connection string for the EF in my intranet web.config file to remove the "OR's" from the string:
/Ecomedate.csdl|res:///Ecomedate.ssdl|res:///Ecomedate.msl;provider=System...
to
;provider=System...
(based on this post: Sharing Entity framework objects across projects?)
I've spent many hours working on this and searching forums and posts. I know there has got to be a way to do this otherwise code reuse and DLL sharing seems useless, so any help you can suggest would be appreciated.
Here is are additional efforts that I have made and in response to some of the post so far.
Also here is what I have experienced with the GAC so far.
- on a computer with VS2010 installed, the gacutil is located in C:\Program Files\Microsoft SDK... and from forum on questions "Where is the gacutil" the general tone is that gacutil is now considered a dev tool and not intended for use in prod environments. Gacutil is not part of the Server 2008 or .Net 4 framework, so there are several suggestions on how to deploy and deal with GAC dlls
first, the old way of installing, using the gacutil, but by using psexec to copy and call gacutil on the production server. I can get psexec to run the gacutil from a local dev box to a prod server and get a return code of 0, success, however I cannot find a way to actually view that it is installed on the production server, because there is not gacutil on prod server, I can't use someting like gacutil /l DataEntity.dll to view info on installed dll...if it even installed correctly.
I tried copying the gacutil.exe and gacutil.exe.config files to production server to try and run from there. While the program run and gives the version number of the gacutil, it doesn't respond to any command line switches such as gacutil.exe /i DataEntity.dll or gacutil.exe /l DataEntity. It just displays the gacutil version info again and stops.
Someone suggesed on a forum to installing the Microsoft SDK on the prod machine. While I might have to consider this due to lack of success so far, I really don't like the idea of installing an SDK on my production evironments.
I tried to find tools such as the Remote GAC Manager to view and manage, but the last development on that opensource project was 2008, so when I try to use it to veiw the GAC, it is wanting to show me c:\Windows\assembly gac dlls, but .NET 4 now uses C:\windows\Microsoft.NET\assembly to store GAC dlls, so I can's seem to find any way to view or maintain DLLs on the remote production server's gac. If I run a dir DataEntity.dll /s command at c:\windows in the command prompt, I find the dll embedded in the C:\Windows\Microsoft.NET\assembly\GAC_MSIL directory, but if I try to look at the file through explorer in C:\Windows\Microsoft.NET\assembly\GAC_MSIL, I cannot see the dll, so I cannot find a tool that allows me to manage (install, list, uninstall) the DLLs in C:\Windows\Microsoft.NET\assembly\GAC_MSIL on the server 2008 production server.
There was a suggestion to install dlls into gac via drag and drop. I am trying to automate our deployment process, so having to manually drag and drop doesn't make a lot of sense. Does a copy to the C:\Windows\Microsoft.NET\assembly\GAC_MSIL directory work too? I've tried it, but again since I cannot find a tool that will let me see the installed/registered DLLs I can't tell if it worked or not.
another suggestion was to create an installer that would just install into the GAC. I tried this method and ran into a couple of issues. First it was a very manual process. I could not figure out how to get it to uninstall the old dll from GAC and then install the new version of DLL in gac; it kept insisting that I uninstall the previous installation first. Second, when I tried to uninstall the dll, it kept saying that it was in use by another application. I tried restarting and then uninstalling it, but no go. I finally figured out it was IIS and had to shutdown IIS, uninstall, restart, install, and then restart IIS. This is a pain in the but to try and automate.
Seems like there should be a better way to deploy dlls to a production environment into a shared directory. I simply want to try and put the DataEntity.dll in a c:\MyLibraries directory and have the processes access that one copy of the DLL. Microsoft does it with the C:\Program Files\Common Files, so it should be possible, but I have now spent days trying to find a way that works that would considerabley reduce the maintenance efforts imposed by the GAC or installer options, reduce the number of duplicate dlls, and avoiding overlooking replacing dlls if allowed to 'copy locally'.
the best solution for your problem is using Web Services.web services are created for this purpose.You can build a WCF service library and then use it's methods in all of your projects.
Good Luck
The GAC approach is probably the closest one to what you are looking for. Since you were unable to get the GAC working, you should double check to makes sure you followed the instructions for installing in the GAC.
This may seem pretty "out-there" as a solution but we are considering using a Git Repository to do a remote publish to multiple servers, the Git repository would be committed with the latest DLL(and only the DLL), then pushed to each production server/application server.
What exactly is needed for someone to use my C# windows application in executable form? I do know that .NET framework has to be installed on the computer, but I heard there is much more. And is there any way to spread the application besides doing installable form via "Publish"? I mean, which project files are needed? Only exe file, or these pdb and manifest files too? Do they have to be from bin/debug or bin/Release, or makes no difference? (I know files created with this application are saved in "debug") Because I need to show my program (as exe) to certain person with .NET framework...
You only really need the .NET framework, unless you've used third party components.
If you use a Package and Deployment project in your solution it will automatically generate a .msi file for you with everything that your app needs to be installed.
You need .pdb files if you want file and line number detail in any exceptions thrown by your app. If you're selling the app as a product, don't include them as that information poses a security risk. If it's an internal app, then consider including them in your package and deployment project, because it's useful information to get with exception logs.
For runtime etc, .NET should be enough. Or with some tools (like as is used via MonoTouch and some others), not even that.
For the application, just the exe is necessary, but there can be lots of other required files - a config file perhaps, or maybe supporting non-CLR dlls (third party dlls perhaps).
For deployment, you can just use the exe etc (xcopy deployment), or ClickOnce (.application), or an installer (.exe / .msi).
The best option is to give them the files from your bin/release folder.
PDB files (which you should only find in your debug folder) contain the symbols for debugging your application, so you don't need to give them those.
There are other options such as ClickOnce deployment or an MSI, but it sounds like you just need to temporarily show this to only one individual, so it won't be worth it to go down this path.
In short, as long as the user has the correct version of the .NET framework installed on their machine, and you give them all of the relevant files from your bin/release folder (the EXE file, any additional DLLs that your application references, and any miscellaneous files like an app.config file), they should be able to run it just fine.