Very simple Winforms application I want to deploy manually. Can all the referenced assemblies simply go in the application folder or where should they be published? (In ASP.NET they can go in the \bin folder). I would rather not put in the GAC.
By default I place the referenced assemblies in the same folder I deploy the app to (or \bin for ASP.NET), barring a Very Good Reason to deploy to the GAC.
You can use .NET probind to define a relative folder where the application should search .dlls at start. You only need to add a simple config file with your application.
For simple apps, I deploy the executable and the config file in the root directory, and place the needed libraries in a lib subdirectory:
/
|-MyApp.exe
|.MyApp.exe.config
|-lib
|-Lib1.dll
|-Lib2.dll
Use this link from a recent anwer to find out how to create the config file
Eric J's answer is probably the correct one, but there is a reason to be wary of placing the assemblies in the application folder: Windows 7. I haven't run into this problem personally, since I'm still in Vista Hell, but apparently in Windows 7 the Protected Administrator account (which you normally run under) doesn't have write access to all application folders - it only has write access to application folders that were installed by that user. So if your application was installed by a Windows XP or Vista user, and then that user upgrades to Windows 7, your default Protected Admin user will be denied write permission on the application folder (since it has a different SID under the new version of Windows).
This problem would only affect you if you try to upgrade the dependent assemblies, and it would only affect users who installed your application under an earlier version of Windows and then upgraded to Windows 7, so I don't know how big a deal this would be for you.
See this article for more details.
Related
I have tried to create an .exe file to my WPF App and SQL Server related databse with EF Core using Windows Setup Installer Project.
I included all the dll's files from /bin/Release and built it for any CPU.
The Setup Project has been created successfully and it worked on my PC as I expected.
Otherwise when I try to install the Setup File on another PC, I can't even open it up and see what's wrong.
I guess the problem comes from the database but I can't find anything helpful on the internet.
So you get the application installed, run it and nothing happens, right? Here is what you do:
Run it. Watch nothing happen
Hit the Windows key and type "Event"
When "Event Viewer" appears in the list of applications, run it
In Event Viewer, go to Windows Logs >> Application
Near the top there will probably be an error entry. It will probably be related to your application. And if you were missing a key file needed to run your application, like a DLL, the name of the file will probably be in there in the details section
Go back to your installer and add that missing file. Or if that file is part of some support package (like, say, MS Redistributable for Visual C++) then add the installer for that too.
I need a single exe-file on a windows pc executing a .Net WPF program. This file must be signed with a code authentication certificat. With this certificat the exe-file is executed on foreign windows system without system warnings or administration rights after copy deployment by user to a trusted place.
I can do this with VS2019 and .Net 4.7.2. But I want go forward to VS2022 and .Net 6.0. Below a simple sample working with VS2019. You can step over signtool, because in VS 2022 already fails the posibility to create a single exe files. Same happens with VS 2019 and .Net 5.0 already in the past, but I find some post with information that single exe-file with WPF first work in future with .Net 6.0. Now, after release of .Net 6.0 and VS2022 I try it again. More options in deployment assistent for single file are available, but nothing creates a single exe-file!
Working process in VS2019:
I create WPF-App (.Net Framework) WPF4Test using .Net Framework 4.7.2
I put code sign command ("C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" sign /a /n "my company name" /t http://timestamp.comodoca.com/authenticode $(TargetPath)) in postbuild step
I build release and enter password of certificate during sign process
bin\Release folder contains 3 files (WPF4Test.exe, WPF4Test.exe.config, WPF4Test.pdb)
I copy WPF4Test.exe to share folder and application is executable and signed
I test process in VS2022 with .Net 6
I create WPF-Application WPF6Test using .Net 6.0
I deploy Application in a folder (in assistant i must select folder twice) (default set configuration Release and destination runtime portable)
pubxml is created and i publish application
deployment folder contains 5 files (WPF6Test.deps.json, WPF6Test.dll, WPF6Test.exe, WPF6Test.pdb, WPF6Test.runtimeconfig.json)
I copy WPF6Test.exe to share folder, but application not start without error message
If I copy the whole folder to share and application run.
I can delete WPF6Test.deps.json and WPF6Test.pdb, but i need 3 files (WPF6Test.dll, WPF6Test.exe, WPF6Test.runtimeconfig.json).
I go back to VS2022 and add additional pubxml file with changed profil option (deploment mode independent, create single file, activate compile ready to run).
But now I get 7 files (D3DCompiler_47_cor3.dll, PenImc_cor3.dll, PresentationNative_cor3.dll, vcruntime140_cor3.dll, WPF6Test.exe, WPF6Test.pdb, wpfgfx_cor3.dll).
What do I have to do to get a single exe file?
How I can sign this exe file during publishing process?
You need to set 'IncludeAllContentForSelfExtract' in the project file or if you using the CLI to build 'IncludeNativeLibrariesForSelfExtract'.
Even if you tick or set single exe if you are producing a self contained exe it will not including the native libraries.
Project File (your-project.csproj)
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
.Net CLI
dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true --self-contained true
Edit your publish profile settings,
Select Deployment mode as Framework-dependent
Select the target runtime to something other than Portable (Produce single file is not available for Portable)
Under File Publish options, select Produce single file
Save the profile settings and try publishing again.
This should produce a single exe file.
If you select the Deployment mode as Self-Contained or independent, it will produce 7 files as you mentioned.
Hope this helps for publishing to a single file!
Using Visual Studio 2017 on Windows 10, I have a WPF application with an installer created using the Visual Studio Installer extension. When I install it on another PC, the application starts but then exits within the same second. Nothing in logs.
If I add a manifest to force admin mode, its starts correct.
If I copy the files to another folder (outside program files) it starts correct.
Apparently the "program files" is restricted or something? Am I missing something in my setup/installer project? Any other ideas more than welcome!
EDIT:
I've tried to create the installer using WIX and then it runs fine. Seems to be some settings in the VS Installer extension.
You can modify the ACLs on the folder in question to allow write access by regular users (not great) or you could write the settings file somewhere else where write permission for users is standard.
There are many ways: Resolve lacking permissions.
There is another, similar answer here.
Adding a couple further links:
WiX and deployment links, various topics.
I installed a silverlight app on Windows 7, it put up a shortcut on the desktop and it works fine. E.g. works fine without internet connection.
What worries me is, it's unclear where exactly that app now is on my machine. I examined this desktop shortcut and it says "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" [Random Integer].[Url Name associated with the app]
Yeah, great. So where is the executable/assembly/whatever that will actually get loaded by sllauncher.exe?
ETA: ok, this guy http://www.qa.com/about-qa/blogs/2011/september/where-is-an-out-of-browser-silverlight-xap-stored/ claims that Silverlight files have extension XAP and are saved in C:\Users\Username\AppData\LocalLow\Microsoft\Silverlight\OutOfBrowser . Not sure how true that is in general, but this is not the case for the specific case of my machine. AFAICT my OutOfBrowser folder is very small, contains no XAP files, no hidden files etc.
ok, so it turns out that the XAP package was not installed in C:\Users\Username\AppData\LocalLow\Microsoft\Silverlight\OutOfBrowser as suggested by the friendly Silverlight trainer-and-blogger-too. No, it was installed in C:\Users\Username\AppData\Local\Microsoft\Silverlight\OutOfBrowser .
"because we are not satisfied until you are not satisfied" http://www.despair.com/cudi.html must be the Windows team's new motto.
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.