ILMerge, ISVs and composite assemblies…

Earlier I made a post about the prefix given to server controls and Robert commented that he did not like the fact that you could not specify the same prefix for controls hosted in different assemblies.

 

If you ask me this only makes sense because there is a true physical distinction between the controls being that they are in different assemblies and the fact that the system forces this to be represented in prefixing just makes good sense. However, his comment got me thinking about various control vendors who sell multiple asp.net controls. In a lot of these cases, I may want to buy 3 of their 7, not all and this while not really problematic; it is not elegant for my perspective in that now I have 3 different assemblies.

 

Enter ILMerge coupled with a little engineering and a component vendor could roll composite assemblies for customers in an ala carte fashion. I pick the three components I want, give my visa number and their purchasing pipeline fires off an ILMerge process that creates a single assembly with just the componentry I wanted.

 

I know, I know – you can do this already. Modules are one way, having different build profiles another - there are a number of ways…Just thought this would make cool use of ILMerge and then Robert would not be able to complain about his different prefixes because his controls would be composed all in one assembly.

1 Comment

  • No dice, Keith. All of my products are packaged up in MSIs. The only real solution is to roll everything into one assembly, and use the XHEO|Licensing solution to limit the classes that the license will allow you to access. It sucks though because you have to roll everything up into one DLL, which is not ideal when you're delivering small controls. We'll have to see where it goes, but that solution still does not help control vendors.

Comments have been disabled for this content.