This is my first time trying to make a deployable program. After creating a nice little WPF XAML app that runs (i.e. I can run the executable in the bin folder), I am trying to wrap it in a setup program.
After following multiple directions online for both WiX and "Microsoft Visual Studio Installer Projects". Both make installer packages, but they are only targeting the dll file from the WPF XAML output when I as for the "Primary Output". It seems this is stemming from the build of the WPF project.
How do I adjust the primary output of the build process so it is included in the setup program?
Screenshot of build output specifying the dll as the output file:
To add more details:
This could be one wpf(.net core) application instead of one wpf(.net framework). See the Output window in Elton's screenshot we can find the output is xx.dll instead of xx.exe.
If we create a Installer project in this solution, right-click the Installer project=>Add=>Project Output=>Primary output to contain the WPF's output in installer project, only the xx.dll is considered as wpf's output, but not xx.exe.
So after building the Installer project in VS, double-click the setup.exe(installer project's output), the wpf.exe is not well installed.
On top of Lance answer. You can add the publish items to your outputs near your main Primary Output.
1- Right-click on project and select Add => Project Output.
2- Choose your target project and select Publish Items from the list with your configuration.
3- Now you have another Output in your Application Folder.
Done. with every Batch Build you have your publish directory copied to application folder.
My Visual Studio 2019 WPF app is setting a dll as the output when it
should be an exe.
I'm sure you're using a WPF(.net core) project cause yesterday I happened to reproduce same situation in my machine. As for the cause of the issue, if you're interested in it, you may get some help from this issue. For .net core 2.2 and earlier, if we build a console(.net core) project, we'll get a xx.dll as output by default(Use dotnet xx.dll to run that).
But for .net core 3.0, I found this situation changes. Now if we build a Console(.net core) or WPF(.net core), apart from the xx.dll, we'll also get an xx.exe now. And I checked the Updated date of Installer Project and the Release date of WPF(.net core), the latest update of the Installer project is much earlier than the release of WPF(.net core), I guess maybe this is the cause? I'm not certainly sure how Installer Project recognize the output of one WPF project, but I suggest you can post this issue in DC forum , if it gets enough votes, the team will consider a fix.
Here're my workarounds which may help:
1.Use Add=>File instead of Add=>Primary Output:
Build the WPF project in release mode, navigate to the output path and copy that path. Then right-click Installer project=>Add=>Files to enter that path. Choose all files in output folder and click open:
Right-click the assembly file and choose Find in Editor:
Right-click the xx.exe=>Create a shortcut. Then move the shortcut to User's Desktop folder and set the AlwaysCreate property to be true.
After that, build the installer project and install that xx.msi or setup.exe in my machine, I'll get a shortcut in desktop, double-click it will run the wpf(core) application.
2.See this blog, we can use command like dotnet publish -r xxx -p:PublishSingleFile=true to get a single-file executable which is self-extracting and contains all dependencies (including native) that are required to run your app. In this situation, you don't need a Installer project to deploy your project. The single executable is enough. Hint from Lex Li in this issue.
Hope it helps :-)
This is my first dabble into Setup Projects.
I have Solution in VS2013.
Within the solution is a C# Winform project, and a Setup Project.
On first build, I can use the setup.exe to install my application on my laptop; no issues.
However, when I make changes to my Winforms, these are not reflected by any subsequent re-install.
Quite simply, the build does not pass winform changes to the setup package.
To explain:
I make changes to a form, for example I add a label or button.
In my setup project I increase the version number.
VS automatically generates a new Product Code.
Build all.
Copy the setup.exe + msi from the setup project's debug folder.
Paste to desktop.
Execute setup.exe
Install completes successfully.
Control Panel > Programs, confirms the new version number.
Yet running the app, none of my form changes are there !?
Hope someone might be able to explain what's going on, what I am missing !?
Many Thanks
A Visual Studio Installer project will automatically pick up the right version of the application if you add the Primary Output of your application. So that's that.
It could be that Visual Studio does package the new version of the executable, but it does not get installed, because you forgot to increase the executable's version number, too (not just the installer's version number!). AFAIK, Windows Installer replaces files only if the version number differs.
What happens when you uninstall the old version before installing the new version? Do you then see your changes? If that's the case, try increasing the version number before the next update.
Change all version numbers of your hosted application in AssemblyInfo.cs together with Version number and Product code in your installer (Setup project).
Using: Visual Studio 2012 Professional and Ultimate with all latest updates
How do I properly specify the configuration and platform to properly build x86 and x64.
Visual Studio, when you first create a Winforms application gives you two configurations, Debug and Release, with AnyCPU defined as the platform.
If you just target one platform, then the answer is easy, you go to the Build | Configuration Manager and select one of the platforms and then go to the project properties' build page and select the same platform (x86 or x64) and voila! You wind up with (say you want x86)
/bin/x86/Debug
/bin/x86/Release
I have a solution with one application and multiple dependency projects (DLL assemblies).
Since the VS Configuration Manager has two dropdown lists at the top, Configuration and Platform and then on the project level another configuration and platform, I did the following:
(Before typing further, I think the whole setup sucks, but...)
I created two new configurations Debug64 and Release64 using the top most dropdown and selected Mixed Platforms for the platform.
I selected each of the four main solution configurations in turn and then set the project level configuration and project level platform to match, so:
Debug64 === Debug64, x64
Release64 === Release64, x64
Debug === Debug, x86
Release === Release, x86
I then went into the project properties (Alt + Enter) build page, ignored the platform and selected each configuration in turn and then set the target processor to match. I changed the output to be the following:
Debug64: /bin/x64/Debug
Release64: /bin/x64/Release
Debug: /bin/x86/Debug
Release: /bin/x86/Release
By default, Visual Studio uses the top platform to set the folder and the configuration name to set the last part of the output. If I save and close out of the project properties, then all seems fine. I can build, and wind up with the proper folders.
The problem comes, when I switch solution configurations on the Visual Studio toolbar. The project properties build page reverts back to what it wants by default, namely, say, /bin/x64/Debug64 for both debugs and something similar for the release.
What prompted me to write this issue is that the designer gets confused and cannot find the appropriate library.
I would like to select from the Visual Studio solution configuration dropdown my desired target (Debug x64, Release x64, Debug x86, Release x86) and have it build.
How do I do that? What am I doing wrong?
Creating just two solution configurations, Debug and Release, does not work, because there is no solution platform dropdown, which then targets all sub-projects. Visual Studio has, it seems to me, way too many configurations sections and platform sections. Maybe I am just missing something.
For posterity, here is the answer. It may sound obvious, but it was not to me, so...
Notes: Creating Debug64 and Release64 were mistakes that cost me. I not only had to remove the Debug64 and Release64 present in the solutions (in Configuration Manager), but I had to delete the automatically generated Debug64 and Release64 for each of the projects (also in Configuration Manager, just in the table part). That took a while.
Make sure that you have the automatically generated debug and release solution configurations.
In the solution platforms add in x86 and x64. The default is Any CPU.
Select from the solution configuration and platform dropdowns the various permutations of (Debug/Release and x86/x64). Make sure the projects match, which they should.
Go into each project (select project name and then Alt+Enter).
In the project properties page, select the various permutations of Debug/Release and x86/x64 in the solution dropdowns. Make sure the target processor is set correctly (it should be, but I found instances when they were not, probably because of my previous attempts). Also, set the output directory. That should be okay and automatic (/bin/x86/Debug, etc.). If not, fix.
Microsoft does not have a solution platform dropdown in the toolbar, so if you want to change solution platforms, then you must go to the Build | Configuration Manager and select the appropriate solution platform. You can select the solution configuration either from the Build | Configuration Manager (Visual Studio will automatically update the selected solution configuration in the toolbar dropdown) or simply select the new solution configuration in the Visual Studio dropdown.
Building the project will take care of the rest.
Build Notes
1. The Visual Studio designer requires x86 versions of user controls in order to display properly. That was not obvious at the onset, but is now. Visual Studio installs to the "C:\Program Files (x86)" folder and not the "C:\Program Files" folder, making Visual Studio a 32-bit application, not a 64-bit one, hence its ability to "use" only 32-bit versions in the designer.
There might be stray /bin/Debug and /bin/release folders, but they will not be used.
I am still trying to get BuildVersionInc to not increment when building the same code through on different configurations, but that is a different issue.
I have two projects, ProjectA and ProjectB. ProjectB is a console application, which depends on ProjectA. Yesterday, everything was working fine, but suddenly today when I run ProjectB I get this:
BadImageFormatException was unhandled:
Could not load file or assembly 'ProjectA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Both are just regular projects, with no dependencies on any other non-.Net projects. Both are fully .Net - there is no native code, and no P/Invoke. I have other projects which depend on ProjectA and still work just fine.
Things I have tried:
Make sure both projects are set to "Any CPU," with the build checkbox checked. They are.
Make sure both projects are for the same Target Framework (.Net 4.0 Client Profile).
Under ProjectB --> References --> ProjectA --> Properties, make sure "Copy Local" is set to "True" _ (I verified that ProjectA.dll is being copied correctly)
Clean/Rebuild the solution. I even tried manually deleting the /bin and /obj folders in both projects.
Restart Visual Studio. Restart my computer.
Check out an entirely new copy of the repository.
But I still get the same error. I have no idea what I did to cause this, nor how to fix it. Any ideas?
I am pretty sure you're having a 32-bit / 64-bit conflict. It sounds like your main project might be set to 32-bit while the class its referencing is set to 64-bit. Try looking at this SO question and this one too. Between the two of them, you should be able to figure out your problem.
Might be you are facing the problem with your website after deploying on server.
Then you need to adjust your application pool to Enable 32-Bit Applications.
Steps
Open IIS Manager
Click on Application Pools
Select whatever application pool you are using
From right pane, click Advanced Settings...
Set Enable 32-Bit Applications to True
I just had this error message running IIS Express in Visual Studio 2015. In my case I needed to be running the 64 bit version of IIS Express:
Tools → Options → Projects and Solutions → Web Projects
Check the box
that says "Use the 64 bit version of IIS Express for web sites and
projects".
Screenshot:
I had this same problem. I had set Project A's "Platform Target" ("Project A"(Right Click)->Properties->Build->"Platform Target") to x86 but kept Project B's at "Any CPU". Setting Project B's to "x86" fixed this.
I had this problem running unit tests (xunit) in Visual Studio 2015 and came across the following fix:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
You may need to change the Appication Pool setting "Enable 32bit Applications" to TRUE in IIS7 if you have at least 1 32bit dll\exe in your project.
First of all I got this in VS2017 with an old project I needed to make a tiny change to and upraded all the projects to framework 4.7.
Several others have mentioned selecting Any CPU can fix this issue.
There's a couple places you need to do it, and it might not just be as simple as selecting from the dropdown. This fixed it for me:
1) You need to do it both here:
2) And also in Configuration Manager (right click on solution)
But what if it isn't there???
Then click New and choose these settings: (thanks #RckLN)
I had the same issue with multiple projects in the same solution, i ended up setting all of the target frameworks to .NET Framework 4 and x86 for the target CPU and it finally successfully compiled.
None of these solutions worked for me - but by deleting the contents of bin and obj folders everything was cool again.
The following solved the issue for me, uncheck 'Prefer
32-bit' :
For the newer version of visual studio (v16.10 for this answer), it can be fixed by manually changing the solution platform. For me it worked after changing from "Any CPU" to "x86".
Click on solutions platform dropdown, the one in which any CPU is appearing in image below.
Go to configuration manager.
Click on new and add platform x86 or x64 (32 or 64 bits) based on what is working for you.
Restart the project.
I also had this problem. As mention before the problem was related to a 32-bit / 64-bit conflict, but with the site hosted in Azure. To change the plattform in Azure App Service, go to Configuration -> General settings.
I got this when building a project via Visual Studio Online (VSTS) Build using Visual Studio Build Steps.
The solution was:
Delete the existing source folder
Explicitly set 'Any CPU' in the platform for all Visual Studio Builds including dependencies (see screenshot below).
Re-run the build
The Chilkat .NET 4.5 assembly requires the VC++ 2012 or 2013 runtime to be installed on any computer where your application runs. Most computers will already have it installed. Your development computer will have it because Visual Studio has been installed. However, if deploying to a computer where the required VC++ runtime is not available, the above error will occur:
Install all of the bellow packages
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x86
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x86
In my case changing IIS Express Bitness from "Default" to "x86" helped.
All my projects had "x86" as the Platform target.
You might also see this issue if you're trying to package a 64bit project with an MSI installer in VS. ("The reason is because the native shim packaged with the .msi file is a 32-bit executable.")
See here for more details: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
I encountered the same issue. It popped up out of the blue and that seemed strange to me.
In the Exception snapshot, for the FusionLog, I saw the following within its message:
... C:\Windows\Microsoft.NET\Framework64 ...
More about the fusion log: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
All the projects had a Target CPU of AnyCPU. I changed the application project (the project that references all the other projects) to a Target CPU of x86. It now works.
Not sure how the Target CPU mix up occurred for no apparent reason, but it did.
I also face this problem in a project, after a few minutes i found the solution,
this problem is due to CPU configuration,
If you are using Visual Studio 2010 or VS 2013, just goto project 's properties and then select Compile from side bar and there will be 5 drop-down, 5th Drop-down will be Target CPU:, you should set it to x86 or x64 according to your requirements instead of Any CPU.
My problem was solved after changing it to x86.
This also can happen just by having multiple supported frameworks defined in the app.config file and, forcing the app to run in a different .NET framework other than the one mentioned first in the app.config file.
And also this fires when you have both of the mentioned frameworks available in your system.
As a workaround, bring up the target framework you are going to use for the debugging up in the app.config
ex: if you trying to run in .NET 4, config file should have something similar to this,
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
In my project for C#, project property->[Build]->Platform target: Any CPU,
and uncheck the Prefer 32-bit to let compiler to choose automatically.
I also had this problem running unit tests by using ReSharper on Visual Studio 2017 and fixed it with following config:
Also you can change the ReSharper's run test setting:
https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration
Shoot! I knew about this problem. I thought I was doing everything right until I accidentally saw 'x86' in the VS output window and that's when I got hold of the cause. Wasted a few mins on it today.
The configuration under 'Publish' window was set to 'x86'; whereas, everywhere else, it was 'x64'.
Please make sure it's in-sync across configuration manager, publish settings, solution configurations, and IIS settings (if that's your web server).
Also, please keep in mind - VS is a 32-bit app and IIS is 64 bit. 32-bit apps are disabled by default in IIS.
It can be a little funny, but I had the same problem with normal working code. I added StreamWriter and StreamReader and it gave that error.
The solution was I took that code into comment brackets then did debug and it started to work again
If you use LibreOffice from your program via cli .net integration like me, I got the same error. I use the older version of LibreOffice on the production environment on my PC I installed a newer version that was in conflict. Just uninstall LibreOffice. I found the solution here .NET CLI: Could not load file or assembly 'cli_cppuhelper'
In my case a dependency was missing in the dll that threw this exception. I checked with Dependency Walker, added the missing dll and the problem was resolved.
More specifically, I somehow corrupted my opencv_core340.dll by accidentally adding SVN keywords to it, and thus my dll could no longer use it. However I don't believe that the solution to this problem depends on whether the dll is corrupted or missing. I'm just adding this for the sake of giving complete information.
I have detected something different from the other answers. Reaching this exception in my project was the result of a corrupt compilation. Without making any changes, just forcing rebuild, it was fixed.
I had the same issue. Project B in my case was a .Net Core Class Library which has a Nuget "Microsoft.Management.Infrastructure" installed. The error was that i called my project B "MI". I changed the project name to something else and suddenly everything worked again.
Interesting as it goes, this can also happen if the folder path is long, which can cause build issues, oddly enough with this cryptic error message.
Just moving the folder up the path, solved the problem!
Are you trying to run your .exe file from the cmd? This was my mistake. Just run the .exe file by double clicking it. If it's a .NET Core SCD for Windows 8.1/Windows Server 2012 R2 x64.
In my case the error was System.BadImageFormatException: Could not load file or assembly 'vjslib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
It was solved by installing vjredist 64 from here.
I have a C# project that I have created in Visual Studio Express 2010. This program uses a 3rd party C# class that relies on/calls a C++ dll. I just copied the filename.dll into the bin/debug and bin/release folders of the project folder, and the application ran fine.
I am under the assumption that I can copy the release executable for the project to another computer and run it as long as the filename.dll is in the same directory as the executable. However, trying this on another computer with correct frameworks installed, etc. the program crashes with a system.dllnotfoundexception.
Strangely, my friend reports that the program runs on his computer with Visual Studio installed, but not the one without, though I have not actually seen this.
What could be causing this? And how can I get the release executable to run on another machine?
Thanks for any replies!
-Chase
Make sure you have the Visual C++ runtime installed (VS2005,VS2008,VS2010).
If your c++ dll is build by visual studio it may depends on the CRT, two things to check here :
If it depends on the release or debug CRT. Microsoft don't give you the right to distribute the debug version except for debugging purposes so it could be a problem.
Witch version it depends on
The last version from vs2010 could be copied in the same directory as the executable (msvcp100.dll for c++ msvcr100.dll for C)
Previous versions needed to be installed as side-by-side assemblies so running their setup was mandatory (Some versions like the VS2005 one are included in framework install but others like the VS2005 SP1 one need to be installed separately)
In any case the best way to debug such problems is to install Dependency Walker (free) on the computer having problems and let it tell you what dll is missing.
The easiest (albeit maybe not the "best") solution to this problem is adding a Setup project to your solution. A setup project will help you find any dependencies, and make them available during install.
The steps you need to take are the following:
Add a Setup project to your solution (found in Add project.../Setup templates)
Right-click the project, choose "Add/Project output..." and add the startup project of your program.
Right-click the project and choose "View/Custom actions".
Right-click the root node, select "Add Custom Action..." and from "Application Folder" add "Primary output from [your project name here]".
Now when you compile, an .msi installer is created. Run this installer on the other computer, and your program will be installed and runnable. To uninstall, run the installer again, or remove the program from "Add/Remove programs" under Control panel.