I have a prism app where I've added a third party WPF control library to one of my modules.
I get an exception that the dll cannot be found when I run my application. Using fusion log viewer I see that the assembly is being looked for in the shell prject bin rather than in the module.
If I were to add a reference to the shell as well then that would get it working but clearly would break the point of a modular design.
Anyone else have experience of how to get this working?
To handle this kind of deployment problem, I usually execute an xcopy command on Visual Studio project post-build events, to copy all modules dependencies and even modules themselves ( when there are no direct references between projects, and that should not be the case normally) into the running folder (the shell bin folder).
Riana
Related
Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?
Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.
Reproducing it is extremely simple. I'm using VS2015 Community.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
Why? And how to fix it?
Update
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.
Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.
For more information see:
http://www.github.com/iswix-llc/iswix-tutorials
I am developing multiple Windows Phone applications that vary only by the content of several files. Applications share the same logic therefore I created a project and multiple folders, one for each app variation with variant's assets and files and moved them to separate location. To compile project I copy over files and follow a standard compilation process with Visual Studio.
Now there are only 5 application variations and for now it is suiting solution, but the number is expected to grow to 50 and more. I would like to automate the process and my current idea is to write a batch script to copy files from variation folder, overwrite project files, compile app with a script and to copy xap package to another location.
My two questions are:
Is my idea good resolution of the problem or is there a more graceful way to do this I am not aware of? (manage and develop multiple app variations)
How would I compile windows phone app from cmd?
I think your problem is valid. I ran into a similar requirement in the past (only that it was for Windows 8 Store Apps), and what I did was the following:
Create a "core" project and moved all the shared logic to that project. I then created a sample app project, referenced the core project and made sure the sample app worked the way I wanted it to.
Finally, I converted the sample app into a Visual Studio template. What this basically does is take the project code and create a Visual Studio template you can reuse.
Read more about it here.
Some work needed to be done within the template source code in order to get some of the dynamic parts like app name into specific locations within the code. For example, you can change a class namespace to be the project's namespace by applying the following code in tour class:
namespace $safeprojectname$
You can read more about template parameters here.
Hope it helps.
To compile windows phone applications or any .NET app from command line you should use
msbuild.exe
. You can find more information and samples here.
I have started to use WIX to deploy a WPF application. I have created the .wxs file with the desired interface features etc...
My questions is how to distribute the required .Net files that support my WPF executable? Not the .net framework or sql server express, but the dependencies needed to run my executable.
Should the process include building a msi with VS Installer, then including that msi into my WIX script and running that inside of my WIX msi?
Or, what is the correct process for distributing a WPF executable with WIX?
I don't think your question pertains to WiX or WPF at all. What you need to ensure is that you package up the necessary dependencies along with your installer, whatever they may be. Referencing your dependency files in your installer script should be sufficient.
Here's the process that I follow for any application.
1) Start with a clean VM that represents the least common denominator of a machine I want to target. Let's say WinXP SP2 32bit.
2) Deploy my application by hand and record all of the steps in a word document. Then try those steps on other OS's to make sure you didn't miss anything.
3) Take each of the steps in my document and implement them in WxS. Keep in mind that Windows Installer and Windows Installer XML is a declarative programming language not an imperative programming language. You don't tell it to xcopy files from dir a to dir b, you describe the directory structure and the installer takes care of it.
BTW, of the things you mentioned, your asking for help with what I consider the simple stuff and excluding the harder more complicated stuff.
As an alternative way, you might see also this post Embedding dlls in a compiled executable to embed all the dll needed (like the interop ones for example) using Costura.Fody. Using WIX there is no more need to add any dependent dll as components in the .wsx file.
This is related to this article but is not a duplicate.
I have a WPF app deployed via ClickOnce, and one of the projects in the solution is simple UI-less standalone Winforms app. This exe should live in the same directory of the main wpf exe. What happens after deploying is that this app runs instead of the wpf app. When I looked at the manifest, the entry point was set to the winforms app instead of the wpf app. I am not sure if its alphabetically related (the name of the winforms app is listed before the wpf one in the filesystem after deployment), but what I want to do is change the entry point in the manifest programmatically (via commandline arguments).
MageUI lets you define the entry point, just like RobinDotNet reveals, but is there a commandline switch to do this via mage.exe?
No. That's what I found frustrating with the command line version of Mage. Usually you can do more with the command line version of an app, not less. But there are several things MageUI can do that the command line version can't.
Here's what MSDN says about it...
Mage.exe will also use a simple set of heuristics to detect the main
executable for the application, and will mark it as the ClickOnce
application's entry point in the manifest.
I don't know what those heuristics are, but I would start by playing with the names of the exes. If all else fails, you can...
Generate the manifest with mage.
Modify the entry point in the manifest with your own code.
Re-sign the manifest with mage.
Does anyone know how to specifically include a winforms setup project to be included in the code_drop folder generated when running UppercuTs zip.bat? With the default settings my web applications and WCF services are included, as are the dll's for the solutions core, but not my winforms application/installer
I was just playing around with UppercuT last night, and I ran into the same question.
One tip I found for putting console apps and windows services into the code_drop is to use this Nuget package in your console/windows service projects:
http://nuget.org/packages/publishedapplications
See this for more info:
http://devlicio.us/blogs/rob_reynolds/archive/2011/03/22/published-applications-aka-publishedapplications.aspx
Using this will cause your console/windows service projects to be "published" similary to how a web app is published in the code_drop. However, this isn't what you're asking for, just wanted to point it out if its useful. This also doesn't work for installers.
If your installers are using the default Visual Studio setup projects (.vdproj projects), I haven't tried that, so I can't help there. I do know that MSBuild refuses to build those types of projects (not sure why...), so you might be better off using WiX or another installer technology. You can do an automated build on a vdproj if you run the build by calling devenv.exe directly from the command line, but you can't build those with MSBuild. I did try adding a WiX setup project to my sln, and UppercuT will build the Wix setup project and drop the .msi in the "build_output" folder, but it doesn't copy it over to the code_drop. My thought would be to add a custom post build step to just copy that file over from build_output to code_drop. I haven't had a chance to figure out the logic in the build scripts to see how it chooses which files to copy from build_output to code_drop. If I figure anything out, I'll update this answer.