|
|
|
Community Member
|
|
We're building an SDK that will allow developers to write plugin assemblies for our business runtime. We are considering using PostSharp in the build process to reduce the amount of boiler plate code that is needed in plugins.
One of the requirements is that users' plugins must not be required to depend on 3rd-party assemblies; they can only depend on a single assembly (let's call it Our.SDK.Public.dll) that is part of our SDK.
Using Laos' aspects is currently forcing us to include PostSharp.Public.dll and PostSharp.Laos.dll in every plugin's References, which conflicts with given requirement.
If possible, we would like to link the necessary source files directly into Our.SDK.Public.dll. What does that mean for the build process? What must we do in order for PostSharp to use our assembly during post-compile? Is it even possible to achieve what I described?
Thank you.
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
This is unfortunately not possible. The reason is that PostSharp creates instances of aspect types at runtime and casts them to types of PostSharp.Public.dll. Since, in .NET, assembly names are a part of type identity, you would break type identity when you rename an assembly.
However, it is possible to use ILMERGE *after* compilation. See <!-- m --><a class="postlink" href="http://www.postsharp.org/blog/gfraiteur/postsharp-and-ilmerge">http://www.postsharp.org/blog/gfraiteur ... nd-ilmerge</a><!-- m --> for details.
To be fully honest, there would be a possibility (after some changes in PostSharp) to use ILMERGE before post-compilation, but then it would not be possible to create instances of aspects in PostSharp. So it would work in a similar way than with PostSharp for Silverlight or Compact Framework (which is somewhat cumbersome).
-gael
|
|
|
|
|
Community Member
|
|
|
This is unfortunately not possible. The reason is that PostSharp creates instances of aspect types at runtime and casts them to types of PostSharp.Public.dll. Since, in .NET, assembly names are a part of type identity, you would break type identity when you rename an assembly.
Hm... I wasn't thinking about renaming any assembly. My intention was to take all *.cs files from PostSharp.Public.dll and PostSharp.Laos.dll and copy them to Our.SDK.Public.dll, then modify and rebuild PostSharp.Core.dll and PostSharp.MSBuild.dll to refer to Our.SDK.Public.dll instead of PostSharp.Public.dll.
This should work, no? AFAIU, serializer will now correctly use my assembly's name when serializing types - afterall, everything is now inside the same file.
I actually just finished doing all this (I signed all the rebuilt assemblies using my own key) and everything compiled without errors. Problem is that the whole thing doesn't run. I have the necessary <Import> in my sample .csproj file, but nothing happens when I hit compile. My aspects simply behave as ordinary attributes.
I admit I don't quite understand everything that's going on yet, so it's very likely I missed something. Question is, what?
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
|
Hm... I wasn't thinking about renaming any assembly. My intention was to take all *.cs files from PostSharp.Public.dll and PostSharp.Laos.dll and copy them to Our.SDK.Public.dll, then modify and rebuild PostSharp.Core.dll and PostSharp.MSBuild.dll to refer to Our.SDK.Public.dll instead of PostSharp.Public.dll.
This should work, no?
There is no difference between merging and renaming assemblies. You break type identities in both cases.
PostSharp relies on type identies to detect aspects. If you change type identities (and, I repeat, a type identity is not just the type name, but includes the assembly name), it will not work.
So you cannot cast, for instance, "PostSharp.Laos.OnMethodBoundaryAspect, PostSharp.Public" into "PostSharp.Laos.OnMethodBoundaryAspect, MySDK.Public".
-gael
|
|
|
|
|
Community Member
|
|
|
PostSharp relies on type identies to detect aspects.
I understand. And this detection code is located in PostSharp.Core.dll, yes?
So you cannot cast, for instance, "PostSharp.Laos.OnMethodBoundaryAspect, PostSharp.Public" into "PostSharp.Laos.OnMethodBoundaryAspect, MySDK.Public".
Is the assembly name in this detection code somehow hardcoded to "PostSharp.Public"? I've performed a quick search and couldn't find any reference to this particular assembly, apart from the inclusion in the project References. But I've changed that to refer to my assembly, instead, so it should be fine.
After my experimental modifications, PostSharp now expects Our.SDK.Public.dll everywhere it used to expect PostSharp.Public.dll originally. If you're saying this is not enough, then what else would I need to change?
Just for the sake of this argument:
I assume you, the author, could rename PostSharp.Public if you really wanted to, couldn't you? You'd just need to replace all the references to it with the new name. Basically, this is exactly what I'm trying to do. Well, this, plus merging in the Laos aspects and some of my own at the same time. <!-- s:) -->  <!-- s:) -->
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Sure, I can rename PostSharp.Public, but I would need to recompile PostSharp.Core. My point is that you cannot rename PostSharp.Public without changing PostSharp Core. If you change PostSharp Core, of course, you can do anything, as long as it is license-wise legal.
-gael
|
|
|
|
|
Community Member
|
|
|
If you change PostSharp Core, of course, you can do anything, as long as it is license-wise legal.
Ah, that's what I wanted to hear! <!-- s:) --> <!-- s:) -->
The license thing is perfectly understandable and not a problem, as long as this all works, as we've already discussed via email.
As for my setback... I have successfully modified PostSharp.Core.dll and PostSharp.MSBuild.dll to refer to my new assembly instead of PostSharp.Public.dll. Yet it doesn't run, or at least it does nothing. Can you perhaps advise me how to best determine where the problem is?
Your help is much appreciated!
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
I don't know. You should debug step by step.
1. Is PostSharp invoked at all? If not, the problem is in PostSharp-1.5.targets (there is a text reference to PostSharp.Public)
2. If PostSharp is invoked, debug AutoDetectTask, which should detect required tasks and inject them in the pipeline.
-gael
|
|
|
|
|
Community Member
|
|
FYI: I've solved the problem. I missed the version number comparison in PostSharp-1.5.targets. My DLL was a 1.0 while target expected a 1.5. Doh! <!-- s:oops: -->  <!-- s:oops: -->
|
|
|
|
Contacts
| Terms of Use |
Privacy Policy