2013-03-28 3 views
4

Я получаю трассировку стека, когда я называю:Сериализация исключений в .NET 4.5

XslCompiledTransform.Transform(XmlDocument.DocumentElement.CreateNavigator(), null, StringWriter) 


System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Runtime.Serialization.SerializationException: Type is not resolved for member --MyProject stuff 
    at System.AppDomain.GetHostEvidence(Type type) 
    at System.Security.Policy.AppDomainEvidenceFactory.GenerateEvidence(Type evidenceType) 
    at System.Security.Policy.Evidence.GenerateHostEvidence(Type type, Boolean hostCanGenerate) 
    at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type) 
    at System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext() 
    at System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext() 
    at System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String& typeName) 
    at System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath) 
    at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig) 
    at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig) 
    at System.Configuration.ClientConfigurationHost.get_HasRoamingConfig() 
    at System.Configuration.ClientConfigurationHost.IsConfigRecordRequired(String configPath) 
    at System.Configuration.BaseConfigurationRecord.hlNeedsChildFor(String configName) 
    at System.Configuration.Internal.InternalConfigRoot.GetConfigRecord(String configPath) 
    at System.Configuration.ClientConfigurationSystem.OnConfigRemoved(Object sender, InternalConfigEventArgs e) 
    --- End of inner exception stack trace --- 
    at System.Configuration.ConfigurationManager.PrepareConfigSystem() 
    at System.Configuration.ConfigurationManager.GetSection(String sectionName) 
    at System.Xml.XmlConfiguration.XmlReaderSection.get_ProhibitDefaultUrlResolver() 
    at System.Xml.XmlTextReaderImpl.get_IsResolverNull() 
    at System.Xml.Xsl.QueryReaderSettings..ctor(XmlReader reader) 
    at System.Xml.Xsl.Xslt.XsltLoader.Load(Compiler compiler, Object stylesheet, XmlResolver xmlResolver) 
    at System.Xml.Xsl.Xslt.Compiler.Compile(Object stylesheet, XmlResolver xmlResolver, QilExpression& qil) 
    at System.Xml.Xsl.XslCompiledTransform.LoadInternal(Object stylesheet, XsltSettings settings, XmlResolver stylesheetResolver) 
    at System.Xml.Xsl.XslCompiledTransform.Load(XmlReader stylesheet, XsltSettings settings, XmlResolver stylesheetResolver) 
    at MyProject 

Объект XslCompiledTransform загружает XmlReader, который использует GetManifestResourceStream для встроенного файла .xslt, но я подтвердил, что правильно получить эту информацию.

Я посмотрел на него совсем немного и сузил его до этого звонка, но я не уверен, куда идти отсюда. Кто-нибудь еще испытал это?

Это было на машине Windows 8, но я испытал это на server2008r2 OS

+0

Вы случайно используете свой код в пользовательском приложении AppDomain и используете пользовательский принцип? –

ответ

14

Я испытываю ту же ошибку с .NET 4.5. Я вижу ошибку при использовании nunit 2.6+. Это происходит, когда вы инициализируете XmlSerializer в суб-AppDomain, с объектами, хранящимися в CallContext. Тип объекта в CallContext не может быть разрешен, если для ApplicationBase (bin-path) установлено значение, отличное от sub-AppDomain. Вы можете увидеть ошибку привязки сборки в Fusion Log Viewer: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

В моем случае, если я скопирую сборку с типом в ней на путь bin-path, ошибка исчезнет. Это, конечно, не жизнеспособное решение.

Вы нашли основную причину ошибки?

EDIT: Я установил ее, позволяя наследовать MarshalByRefObject типа: Type cant be resolve in UnitTest after migrating Project from vs2005 to vs2010 (MSTest)

EDIT 2: Альтернативное исправление назвать System.Configuration.ConfigurationManager.GetSection («фиктивный») перед кодом, который терпит неудачу.

+0

В моем случае только сейчас это было (согласно вчерашнему комментарию МайкаГоатли) Принципалу, связанному с 'CallContext'. Моя работа заключалась в том, чтобы защитить «Thread.CurrentPrincipal» в локальной переменной, а затем присвоить ей «new ClaimsPrincipal()», в то время как преобразование Xsl было скомпилировано. (И затем верните его обратно) –

+1

@ Андреас Кроманн, не могли бы вы объяснить, почему вызов 'ConfigurationManager.GetSection()' решает проблему? Я пробовал, он работает, но я не могу это объяснить. – RePierre

+2

Mysterious Fix (2) работал для меня. Наше дело не в том, чтобы задаться вопросом, почему ... – fiat