Bug 15389 - Default constructor not found for type System.Web.Configuration.WebConfigurationHost; needs [Preserve]?
Summary: Default constructor not found for type System.Web.Configuration.WebConfigurat...
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: mmp ()
Version: 1.6.19
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2013-10-14 15:36 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2013-11-13 22:04 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case (5.65 KB, application/zip)
2013-10-14 15:36 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NOT_ON_ROADMAP

Description Brendan Zagaeski (Xamarin Team, assistant) 2013-10-14 15:36:53 UTC
Created attachment 5143 [details]
Test case

Reported on behalf of a user.

## Steps to reproduce

1. Open attached test project.
2. Run the project.


## Result
The line `WebConfigurationManager.OpenWebConfiguration("~/");` throws an error:
"Default constructor not found for type System.Web.Configuration.WebConfigurationHost"


## Workaround
Preserve the WebConfigurationHost default constructor, so it isn't linked away. For example, Add `--xml=${ProjectDir}/desc.xml` under "Project Options -> Mac OS X Packaging -> Advanced Mono Bundling Options -> Extra Arguments". An appropriate `desc.xml` file is included in the test project for convenience.


## Version information
Xamarin.Mac 1.6.19


## Stack trace

> System.MissingMethodException: Default constructor not found for type System.Web.Configuration.WebConfigurationHost
>   at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in <filename unknown>:0
>   at System.Activator.CreateInstance (System.Type type) [0x00000] in <filename unknown>:0
>   at System.Configuration.InternalConfigurationSystem.Init (System.Type typeConfigHost, System.Object[] hostInitParams) [0x00000] in <filename unknown>:0
>   at System.Configuration.InternalConfigurationFactory.Create (System.Type typeConfigHost, System.Object[] hostInitConfigurationParams) [0x00000] in <filename unknown>:0
>   at System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration (System.String path, System.String site, System.String locationSubPath, System.String server, System.String userName, System.String password, Boolean fweb) [0x00000] in <filename unknown>:0
Comment 1 Sebastien Pouliot 2013-11-13 22:04:31 UTC
This is normal. The linker use static analysis to detect what must be kept vs what can be removed.

System.Configuration (both the namespaces in several assemblies) and the System.Configuration.dll use reflection to dynamically load types (including lots of System.Configuration.* types).

This is not something that can be handle by static analysis (and one of the main reasons why those API were removed from the MOBILE profile used by Xamarin.iOS and Xamarin.Android).

Solutions are to:

a) Disable the linker, either globally (e.g. --dontlink) or on some assemblies (e.g. --linkskip=System);

and/or

b) Include additional instructions (e.g. an xml file like you did). They must match with the machine.config that will be shipped with the application;

and/or

c) Avoid API that depends on System.Configuration;

A future version of Xamarin.Mac will be based on the MOBILE profile and won't have System.Configuration dependencies. OTOH this issue will remain for projects that chose to target the "full" profile shipped with Mono.