I'm working on automating the installer for a .NET 4.0 ClickOnce WPF application, which needs a few items to be set in the app.config file. I've gone through the thorny process of finding specific steps I must follow using Mage.exe (that is, update and re-sign application and deployment manifests) and now am trying to automate it for installation.
I opted to use .deploy extension to minimize issues with IIS/Internet Explorer security mechanisms, so essentially the algorithm is as follows (based on Signing and re-signing manifests in ClickOnce (Saurabh Bhatia) and Update Configuration of a ClickOnce WPF Application Using Mage or MageUI, as primary sources among others):
\Application Files\App_%HighestVersion%\
foldermage -u %app%.exe.manifest -cf cert.pfx
mage -u %app%.application -appm %app%.exe.manifest -cf cert.pfx
%app%.application
2 levels up (to ..\..
- deployment root)That works perfectly if done manually. I can run a .cmd file, customized for environment specifics (paths, etc.), but then I'd need to include mage.exe
in the deployment, and whether Microsoft allows us to do that is an open question for me. Thus, I'm trying to perform similar actions in the Installer
class:
X509Certificate2 ct = new X509Certificate2(sPathCert);
// .. Remove .deploy extension (for files in the sPathApp folder).
sPathMft = Directory.GetFiles(sPathApp, "*.exe.manifest")[0];
ApplicationManifest am = ManifestReader.ReadManifest( "ApplicationManifest", sPathMft, false ) as ApplicationManifest;
if (am == null)
throw new ArgumentNullException("AppManifest");
am.ResolveFiles();
am.UpdateFileInfo( );
ManifestWriter.WriteManifest(am, sPathMft);
SecurityUtilities.SignFile(ct, null, sPathMft);
// .. Restore .deploy extensions to files touched above.
sPathMft = Directory.GetFiles(sPathApp, "*.application")[0];
DeployManifest dm = ManifestReader.ReadManifest("DeployManifest", sPathMft, false) as DeployManifest;
if (dm == null)
throw new ArgumentNullException( "DplManifest" );
dm.ResolveFiles();
dm.UpdateFileInfo();
ManifestWriter.WriteManifest(dm, sPathMft);
SecurityUtilities.SignFile(ct, null, sPathMft);
File.Copy(sPathMft, sPathBin + "\\" + dm.AssemblyIdentity.Name, true);
Now, here's the kicker. Everything works perfectly with exception of step 5. When the application is downloaded to the user's machine there's an issue with the deployment manifest:
Indeed, this section is no longer present (however, it was in the original %app%.application!). A similar outcome is described in ClickOnce - .NET 4.0 errors: "Deployment manifest is not semantically valid" and "Deployment manifest is missing <compatibleFrameworks>", but is a result of a different process (msbuild). This section is new (and required) for 4.0 manifests, so my only guess is that somehow when ManifestWriter persists changes to disk it does it in a 3.5 fashion? I triple checked that a correct library is used (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\Microsoft.Build.Tasks.v4.0.dll). What gives?
In lieu of an answer so far I tried to add the missing section manually:
dm.CompatibleFrameworks.Clear(); // Unnecessary as dm.CompatibleFrameworks.Count == 0 indeed!
CompatibleFramework cf = new CompatibleFramework();
cf.Version= "4.0";
cf.SupportedRuntime = "4.0.30319";
cf.Profile= "Client";
dm.CompatibleFrameworks.Add(cf);
cf = new CompatibleFramework();
cf.Version = "4.0";
cf.SupportedRuntime = "4.0.30319";
cf.Profile = "Full";
dm.CompatibleFrameworks.Add(cf);
But that has no effect, no matter where I place this code, before dm.ResolveFiles( ), dm.UpdateFileInfo( ) or ManifestWriter.WriteManifest(..)!
My result is similar to Stack Overflow questions MageUI.exe removes compatibleFrameworks element or Why does Mage.exe not generate a compatibleFrameworks attribute? or MageUI.exe is not including a compatibleFrameworks element, but I'm not using mageui
, mage
or even msbuild
at all!
What's going on?
Figured it out myself. The culprit is ManifestReader.ReadManifest( "DeployManifest", sPathMft, true ).
MSDN says, [preserveStream argument] "specifies whether to preserve the input stream in the InputStream property of the resulting manifest object. Used by ManifestWriter to reconstitute input which is not represented in the object representation."
Wording aside, setting true is not enough by itself: dm.CompatibleFrameworks.Count
will still be 0, but now the addition of CompatibleFramework
items will have an effect!
For someone else in the same boat, I do that before dm.ResolveFiles( )
:
if( dm.CompatibleFrameworks.Count <= 0 )
{
CompatibleFramework cf= new CompatibleFramework( );
cf.Profile= "Client"; cf.Version= "4.0"; cf.SupportedRuntime= "4.0.30319";
dm.CompatibleFrameworks.Add( cf ); // cf= new CompatibleFramework( );
cf.Profile= "Full"; // cf.Version= "4.0"; cf.SupportedRuntime= "4.0.30319";
dm.CompatibleFrameworks.Add( cf ); /// no need for separate object
}
@davidair, thanks for your suggestion! Agreed, though I prefer to work with API objects (vs. XML).
Another alternative is to call mage
(directly or from a .cmd file), as it seems that we are allowed to redistribute it.
I also added the following portion, which doesn't have an impact on the question itself, but may be quite important for anyone following the same path (/client is the deployment root, and can be customized):
dm.DeploymentUrl= string.Format( "http://{0}/{1}/client/{1}.application",
Dns.GetHostName( ), Context.Parameters[ scTokVirtDir ] );
dm.UpdateMode= UpdateMode.Background;
dm.UpdateUnit= UpdateUnit.Weeks;
dm.UpdateInterval= 1;
dm.UpdateEnabled= true;
2019-Oct-08
Just stumbled on an issue with app.manifest
:compatibility
section with supportedOS
elements was stripped out during deployment.
Same root cause; the line reading it should set preserveStream
to true:
ApplicationManifest am = ManifestReader.ReadManifest( "ApplicationManifest", sPathMft, true ) as ApplicationManifest;
I also needed to add CompatibleFrameworks. I also tried do add the CompatibleFrameworks like this (which does not work)
dm.CompatibleFrameworks.Add(...);
My solution was to set:
dm.TargetFrameworkMoniker = ".NETFramework,Version=v4.0";
After this the Manifest generation was correct.
Be careful If you set the TargetFrameworkMoniker before WriteManifest you have the <compatibleFrameworks> twice and your application file is corrupt. Here is my solution for this:
DeployManifest dm = ManifestReader.ReadManifest("DeployManifest", applicationFileName, false) as DeployManifest;
dm.ResolveFiles();
//doing stuff..
dm.UpdateFileInfo();
ManifestWriter.WriteManifest(dm, applicationFileName);
dm.TargetFrameworkMoniker = ".NETFramework,Version=v4.0";
ManifestWriter.WriteManifest(dm, applicationFileName);
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With