Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.ArgumentException: Font '?' cannot be found. In the BootstapperApplication #5282

Closed
Braghar opened this issue Apr 28, 2016 · 2 comments
Assignees
Milestone

Comments

@Braghar
Copy link

Braghar commented Apr 28, 2016

  • Which version of WiX are you building with?
    WiX Toolset v3.10.2
    wix-v3.10.2516.0
  • Which version of Visual Studio are you building with (if any)?
    VisualStudio 2013,
    Version 12.0.40629.00 Update 5
  • Which version of .NET are you building with?
    Version 4.6.01055
  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?
    Windows7 enterprise

We are creating an application, which has some .NET dependencies. To check these dependencies at setup time we use a BootstrapperApplication in the setup, which is a simple library.

The project is built successfully, the setup file is created, it can be started.

After starting the setup program of our application it hangs up after a while. The installer triggers the BootstrapperApplication and the Run method is called.
The problem is an exception: System.ArgumentException: Font '?' cannot be found. It comes at the first usage of SystemFonts (using direct or implicitly over an other API, it does not matter.)
The most simple way to get just use: var sdfsdf = SystemFonts.CaptionFont;

This problem did not come with Wix3.9. We used this version earlier and the problem comes just after changed to Wix3.10.

In the WixBootstrapper Bundle.wxs:

<BootstrapperApplicationRef  Id="ManagedBootstrapperApplicationHost">
  <bal:WixManagedBootstrapperApplicationHost LicenseFile="Resources\MicrosoftNet452EULA.rtf" LocalizationFile="Lang\2057\Texts.wxl" LogoFile="Resources\myprogram.bmp" />
  <Payload SourceFile="$(var.BinaryDir)Microsoft.Deployment.WindowsInstaller.dll" />

  <Payload Name="1031\Texts.wxl" SourceFile="Lang\1031\Texts.wxl" />
  <Payload Name="2057\Texts.wxl" SourceFile="Lang\2057\Texts.wxl" />

  <Payload SourceFile="$(var.TestLib.TargetPath)" />
  <Payload SourceFile="$(var.TestLib.TargetDir)log4net.dll" />
  <Payload SourceFile="$(var.TestLib.TargetDir)BootstrapperCore.config" />
  <Payload Name="de\sdf.resources.dll" SourceFile="$(var.SetupWixBootstrapperApplication.TargetDir)de\SetupWixBootstrapperApplication.resources.dll" />
</BootstrapperApplicationRef>

In the BootstrapperApplication, BootstrapperCore.config:

<configuration>
  <configSections>
    <sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
      <section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
    </sectionGroup>
  </configSections>

  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" />
  </startup>

  <wix.bootstrapper>
    <host assemblyName="TestLib">
      <supportedFramework version="v4\Full" />
    </host>
  </wix.bootstrapper>

</configuration>

The BootstrapperApplication code:

namespace TestLib
{
    public class Class1 : BootstrapperApplication
    {
        protected override void Run()
        {
            try
            {
                var sdfsdf = SystemFonts.CaptionFont;
            }
            catch (Exception e)
            {
                Engine.Log(LogLevel.Error, "Caught Run exception: " + e);
            }
        }
    }
}

The exception:

System.ArgumentException: Font '?' cannot be found.
   at System.Drawing.FontFamily.GetGdipGenericSansSerif()
   at System.Drawing.FontFamily.get_GenericSansSerif()
   at System.Drawing.SystemFonts.get_DefaultFont()
   at System.Drawing.SystemFonts.get_CaptionFont()
   at TestLib.Class1.Run()
@barnson
Copy link
Member

barnson commented Apr 28, 2016

Known issue, scheduled for fix in WiX v3.10.3.

@barnson barnson closed this as completed Apr 28, 2016
@Braghar
Copy link
Author

Braghar commented Apr 29, 2016

Thank you for the quick answer!
Can you tell me when will be this version released?

@robmen robmen added this to the v3.10.3 milestone May 3, 2016
@robmen robmen self-assigned this May 3, 2016
@robmen robmen reopened this May 3, 2016
rseanhall pushed a commit to wixtoolset/wix3 that referenced this issue May 16, 2016
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
rseanhall pushed a commit to rseanhall/wix4-archive that referenced this issue Sep 25, 2016
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
robmen added a commit to wixtoolset/wix4-archive that referenced this issue Jan 7, 2017
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants