|
|
|
Community Member
|
|
Error 13 Unhandled exception: System.InvalidCastException: [A]UUU.VVV.Trace.TraceAttribute cannot be cast to [B]UUU.VVV.Trace.TraceAttribute. Type A originates from 'UUU.VVV.Trace, Version=1.5.3687.31428, Culture=neutral, PublicKeyToken=null' in the context 'LoadNeither' at location 'C:\UUU.VVV.Trace\bin\debug\UUU.VVV.Trace.dll'. Type B originates from 'UUU.VVV.Trace, Version=1.5.3687.31428, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:< Integrated Project>\bin\Debug\UUU.VVV.Trace.dll'.
at UUU.VVV.Trace.TraceTask.ProvideAdvices(Weaver codeWeaver) in c:\UUU.VVV.Trace.Weaver\TraceTask.cs:line 326
at PostSharp.CodeWeaver.WeaverTask.Execute() in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.Core\CodeWeaver\WeaverTask.cs:line 45
at PostSharp.Extensibility.Project.ExecutePhase(String phase) in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.Core\Extensibility\Project.cs:line 1230
at PostSharp.Extensibility.Project.Execute() in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.Core\Extensibility\Project.cs:line 1273
at PostSharp.Extensibility.PostSharpObject.ExecuteProjects() in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.Core\Extensibility\PostSharpObject.cs:line 616
at PostSharp.Extensibility.PostSharpObject.InvokeProject(ProjectInvocation projectInvocation) in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.Core\Extensibility\PostSharpObject.cs:line 547
at PostSharp.MSBuild.PostSharpRemoteTask.Execute(PostSharpTaskParameters parameters, TaskLoggingHelper log) in c:\Users\gael.000\svn\postsharp\branches\1.5\Core\PostSharp.MSBuild\PostSharpRemoteTask.cs:line 113
<Integrated Project Name>
Is there a workaround available for this ?
Thx
Anil
|
|
|
|
|
Community Member
|
|
Hi Gael,
Are there any updates/workarounds to the above exception ?
Thx
Anil
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
This kind of errors generally occur because the CLR "finds" an assembly differently than PostSharp. More debugging is needed to know the concrete reason in your particular case (run the debug build of PostSharp, enable relevant trace categories...).
The problem must have been resolved in PostSharp 2.0, since PostSharp fully controls the way how the CLR finds assemblies.
-gael
|
|
|
|
|
Community Member
|
|
As PS 1.5.6.761 was considered to be most stable release since inception, does that mean PS 1.5 Release still lags the component for CLR handling("find") of assemblies ?
As moving to new Release depletes mitigation of risks and increase side effects of software integration,do you plan to release a patch update for PS 1.5 with the solution to above or PS 2.0 is the only way to go ?
Thx
Anil
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
There is no way to make this patch, since the new CLR finding component was made possible by a major change in the architecture.
You could probably find a workaround, but you would need to see why and when the CLR loads the conflicting DLL, why it has been found on this location. You can do that only by running the debug build and enabling the right trace categories (Domain, ProjectLoader, AssemblyBinder).
For PostSharp 1.5, it is quite difficult to collect these traces; it is described in <!-- m --><a class="postlink" href="http://doc.postsharp.net/1.5/#PostSharp.HxS/UserGuide/Platform/Debugging.html">http://doc.postsharp.net/1.5/#PostSharp ... gging.html</a><!-- m -->. It has been improved in PostSharp 2.0.
|
|
|
|
Contacts
| Terms of Use |
Privacy Policy