Simplier deployment

Dec 19, 2009 at 6:23 PM

I do not really like having to deploy all these assemblies to use combres:

ajasmin.dll, combres.dll, dotcommon.dll, dotcommon.mvc.dll, dotcommon.web.dll, ecmascript.net.modified.dll, fasterreflect.dll, log4net.dll, yahoo.yuo.compressor.dll.

I realize you HAD to take dependencies on some of these things, but on others it was optional.   I already use my own logging, either ELMAH or Enterprise Library.

So, I do not want to have or configure log4net.dll.  This is a great use of IoC where I could plug my own logger into your system.   Or consider I already use it and want a different version.  The other files just make deployment and such messy and are only used for your software and only updated with your new releases.  For that, what about combining them all into one dll?  For example if you use RhinoMock, it makes extensive use of dynamic proxy from castle project - but it is INCLUDED inside so there is only one dll and one dependency to worry about.

To do this combining, you can either use ILMerge tool from Microsoft as a post build step...or you can just hook into the assembly resolver to load them from the resources.  ILMerge may not work with unmanaged code - so may not work - but the other method will. 

http://stackoverflow.com/questions/222655/embedding-assemblies-inside-another-assembly

thoughts?

Dec 19, 2009 at 6:57 PM

BTW, not sure if you  have started messing with www.dotlesscss.com yet or not, but they have several dependencies and I just saw they use ILMerge to produce just one.

Dec 19, 2009 at 7:50 PM

I decided to do the above.  I used ILMerge and then verified the output with PEVerify.  All works great.

Only change was in your config section, the place to look for Microsoft.Ajax.Utilities.OutMode is in combres, not in ajax min.   Other than that everything works great and there is now one dll to distribute.   This can easily be made a post build step by you. 

1)  Rename the output of combres.dll project to something like combresbase.dll.

2)  Run this on build complete step:

"C:\Program Files (x86)\Microsoft\ILMerge\ILMerge" /out:combres.dll combresbase.dll dotcommon.dll dotcommon.mvc.dll dotcommon.web.dll fasterflect.dll log4net.dll ajaxmin.dll yahoo.yui.compressor.dll ecmascript.net.modified.dll

Done.

Dec 21, 2009 at 2:16 PM

Thanks a lot for sharing this.  That's a good idea to use ILMerge.  In the latest code commit, I update the MS Ajax minifier in a way that you don't have to specify the Microsoft.Ajax.Utilities namespace in the config file.  I've also added instruction in readme.txt showing people how to add ILMerge build action (which would also merge dotLess.Core.dll, which is used in since the previous code commit).

Dec 21, 2009 at 2:37 PM

I recommend you put the command at the top in the 'after build' event on release builds and make this the default.

Alternatively you could have another 'build type' - "release-combined" that does this.

What about something to get rid of your logging?  Need IoC (service location) to abstract the logging.  That way I do not need the log4net.

Dec 22, 2009 at 3:52 AM

I guess I'll go with the build type.  Do you know how to assure that the Combres assembly in both build types is named Combres.dll (instead of CombresBase.dll or s/t like that)?  I want to give people option and don't want them to have to modify the config file for the correct assembly (per build type). 

Regarding the logging, a log abstraction & some concrete logger type specified in the Combres' config file would do.  I've added the tracking ticket here: http://combres.codeplex.com/WorkItem/View.aspx?WorkItemId=5633

Dec 22, 2009 at 4:38 AM

In the post build step, you can just output it to a different folder like ./combined or whatever and that way it can be the same final name.

Logger - great.

Dec 22, 2009 at 10:10 AM

Cool thanks.  I was thinking about writing some more sophisticated batch command but I guess that's not quite necessary.

Dec 27, 2009 at 8:28 AM

Addressed.  The post-build-event would look for ILMerge and if found, will create the merged Combres.dll file in the bin/merged folder.  If ILMerge is installed in other location than "C:\Program Files (x86)\Microsoft\ILMerge\".