I have inherited a Windows Forms application and I have found that a .EXE file gets generated into the obj\Debug folder everytime I compile.
I am more a Web Forms kind of developer so I am a little confused as to what is happening here. Why is it a .EXE and not a .DLL? What does this file actually represent? Is this the default behaviour for Windows Forms applications? Or, did my predecessor have to set it up up somehow?
As far as I can tell, the solution does not have a deployment project.
Their are many types of win application in delhpi. If u create windows form, .exe will be craeted in the debug folder similarly if you are creating Dynamic Link Liberary (DLL) .dll files will b created. These files are created each time when you compile the application.
Why this is a problem? Console application projects have exe file in the obj/Debug folder too. The obj folders are NOT used for running the application - they are used for creating the end binaries in the bin folders.
If the question is about exe vs dll then compiled exe file is used to run the application. In the web environment you used dll because ASP.NET new how to run code from it. But Windows knows how to run exe files, so any of your code actually can be compiled to an executable.
Every application be it web or windows would have an entry-point for execution. Anything in compiled form in .Net is an assembly which need not always be a DLL file. An EXE file is a .Net assembly with an entry point and few headers in the beginning of the file that identifies itself as a stand-alone executable to the windows operating system. In case of your web-application your asp.net pages are the entry points that users would type in a browser and start the application. In case of a stand-alone windows forms desktop application, it is an EXECUTABLE file, which user can click on run.
I am more a Web Forms kind of developer so I am a little confused as to what is happening here. Why is it a .EXE and not a .DLL?
Having said this, It is also important to note that, just like the asp.net is not the only platform to develop web-applications [you have php, jsp, etc.], .Net windows forms is also not the only way to create stand-alone executables. You can make EXEs in C, C++, VB, Delhpi, etc. only difference would be that they will not be .Net assemblies but all of them including .Net executables will have an entry-point to start execution from and the EXE header that identifies them as executables on the host windows operating system.
Why would it be a DLL? It's an application - it has to be launchable, unlike a website which lives "inside" a web server (effectively). The exe file is the application (along with any libraries it requires, of course). You double-click on it, it will launch the application. No problem.
Having said that, you should pretty much ignore the obj directory - it's just an intermediate directory. The bin directory is the one you should be taking build results from.
Related
I am running on a system which I don't have administrative access on
An exe I am trying to run utilizes msvcp140.dll, and currently upon running will not run and throw an error message specifying that msvpc140.dll is missing.
Normally I would just install the dll to system32 and be done with it, however in this case I do not have administrative privileges.
Is there a way to map to this dll when running it? Some sort of batch command? Would this have to be somehow linked when compiling? Any advice?
Thanks!
you have the following options:
add the .dll to the directory where your .exe is located. This particular .dll is redistributable, meaning you can include it with your installer, although the proper way is to invoke MS VC++ redistributable installer.
recompile your application to use static linking to C++ runtime. In this case you won't need the .dll at all
I dont think you should copy msvcp140.dll into the system folder in case. System32 is a global folder, so any change of dlls in this directory can affect all installed applications.
This article from MSDN:
Describes how to deploy a Visual C++ application by copying files to
its folder.
Copy the appropriate MFC and C Run-Time (CRT) library files from the Visual Studio installation directory in the \VC\redist\version folder, and then paste them in the \Release\ folder of your MFC project.
This is also relevant for non MFC applications deployment.
I'm using PreEmptive Protection Dotfuscator for winform executable .exe file.
Do I have to add Map.Xml and Dotfuscator1.Xml to Setup Project with other Dependencies to locate it in Program Files/MyApp directory, or it is no needed?
(Disclaimer: I am a developer on Dotfuscator and am answering this as part of my job.)
No, after Dotfuscator has run and created a protected/obfuscated .exe file, you typically do not need to involve the Map.xml or Dotfuscator1.xml files in any later step of your build process. Your protected .exe file will be able to run without them, and they are not needed when building your setup executable.
In fact, these files contain sensitive information that could be used to undo parts of the obfuscation. Do not add these files to an installer project, packaging project, or anything that could potentially leave your organization. For details, including how to handle these files as part of your development process, see my answer here.
I just finished coding my c program in visual studio (VS) and what I had done is just drag the compiled .exe file out of the folder to run it on other computers, except on other computers for that to work I guess I need VS since it says the MSVCR110D.dll is missing which is from VS. So how can I run my program on other computers that don't have VS?
You can use IExpress which is used for distributing self-contained installation packages. It is there in every windows machine preinstalled. Using this utility you can make the executable .exe which will be incorporated with dependent dlls. You can see Step by step guide, to see how to use it.
Follow these steps
https://msdn.microsoft.com/en-us/library/3w7axy17.aspx
In your output window it will show you where you can find the exe file, usually something like "ProjectName/Debug/Release/"
If you have added any external libraries you will have to copy any DLL files in that folder with the exe (You can combine them with some applications if needed)
You will also have to make sure that you have the correct version of the .NET Framework on the PC that you are trying to run your program on
Hey, I was wondering if you guys could see what is wrong/suggest a solution.
I have a dll Assembly for COM that I built with C#, and i am trying to get the COM object from Silverlight Out-of-browser. I want the siverlight application to be mobile between computers, so i put all the neccesary files in a zip along with a batch installer that does the followingto register the assembly:
cd %windir%\Microsoft.NET\Framework\v4.0.30319\
RegAsm.exe "%USERPROFILE%\My Documents\Homework Clock\windowsHook.dll" /tlb /nologo
My application finds the assembly and it works fine on my dev computer, but when I move my application to a test computer (along with the dll and any other neccesary files), my batch file says it registers successfully but the application doesn't find it.
However, when i rebuild the assembly with C# on the test computer and replace the dll i moved from the dev computer with the rebuilt dll, the application finds it fine. It would be convenient for my clients if they didn't have to rebuild the assembly using C# if they wish to use my application, so i was wondering if there was a way to fix this.
I looked into this problem for a while and thought it might be because my assembly wasn't a strong named assembly, since I think C# does that automatically, so i tried doing it in my batch file and it couldn't recognize the 'al' and 'sn' commands necessary to generate the cryptographic key to give an assembly a strong name, and i tried doing it in the
'signing' tab in the C# project properties, but i encountered the same problem. Any ideas how to fix this?
Thanks in advance
The reason it works when you rebuild with VS is because it runs Regasm.exe with the /codebase option. Required if you don't plan to put the assembly in the GAC.
C# does not automatically give assemblies a strong name. If you're using Visual Studio, open the project's Properties page, and look under the Signing tab. Check Sign the Assembly, and generate a new strong name key file. Build your project, and you should be able to do what you need to do with your existing batch file.
I've created a Windows Forms (C#) application called "Image Processing". It uses many external dlls so I decided to use ILMerge to merge all of them into one exe file and it worked. But today I've localized my application. After building I had 3 new folders in Debug folder: "en-US", "ru-RU", "uk-UA" with one dll with the same name "ImageProcessing.resources.dll". So I included all of them in a ILMerge command:
ILMerge.exe /t:winexe /out:ImageProcessingRelease.exe ImageProcessing.exe AForge.dll AForge.Imaging.dll AForge.Math.dll DevExpress.Data.v10.2.dll DevExpress.Utils.v10.2.dll DevExpress.XtraBars.v10.2.dll DevExpress.XtraEditors.v10.2.dll FreeImageNET.dll uk-UA\ImageProcessing.resources.dll ru-RU\ImageProcessing.resources.dll en-US\ImageProcessing.resources.dll
My program stores language locale in settings. After merging I can't change language, but settings are changing.
I don't know what else I can include here for more details so tell me please what.
The answer is simple. ILMerge is not suitable in this case, as .NET Framework relies on the folder structure to determine which resource file to use.
It is meaningless to combine assemblies in that way, and some third party assembly vendor's end user license does not permit you to merge their product with your own assemblies.