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

Comments

Projects
None yet
3 participants
@Braghar

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

This comment has been minimized.

Show comment
Hide comment
@barnson

barnson Apr 28, 2016

Member

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

Member

barnson commented Apr 28, 2016

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

@barnson barnson closed this Apr 28, 2016

@Braghar

This comment has been minimized.

Show comment
Hide comment
@Braghar

Braghar Apr 29, 2016

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

Braghar commented Apr 29, 2016

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

@robmen robmen added bug burn labels May 3, 2016

@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

robmen added a commit to robmen/wix3 that referenced this issue May 3, 2016

Workaround GDI+ security vulnerability
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, all Burn processes that load BAs
will no longer protect themselves from DLL hijacking. In particular, the
clean room and package cache processes will be unsecure. Fortunately,
the design of those processes should be safe without the extra
protection.

Fixes wixtoolset/issues#5282

robmen added a commit to robmen/wix3 that referenced this issue May 4, 2016

Workaround GDI+ security vulnerability
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 robmen/wix3 that referenced this issue May 6, 2016

Workaround GDI+ security vulnerability
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 robmen/wix3 that referenced this issue May 6, 2016

Workaround GDI+ security vulnerability
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 added a commit to wixtoolset/wix3 that referenced this issue May 16, 2016

Workaround GDI+ security vulnerability
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 added a commit to rseanhall/wix4 that referenced this issue Sep 25, 2016

Workaround GDI+ security vulnerability
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 that referenced this issue Jan 7, 2017

Workaround GDI+ security vulnerability
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