development cycle for providers

Topics: Enterprise Library Core
May 1, 2007 at 8:40 PM
I'm building a new provider for the Exception Block.

I have my own C:\EntLib3Src\App Blocks\
I have configured VS2005 to use that directory with the solution property EnterpriseLibraryConfigurationSet
I also have a unit testing in the solution.

The cycle is design, code, debug, deploy, unit test, start over.

When I deploy I'm trying to copy what is in the bin folder of my project into the bin folder of C:\EntLib3Src\App Blocks\ and as one would expect I get:

Cannot copy Intella.ProviderLibrary.ExceptionHandling.Configuration.Design: It is being used by another person or program.

The only way to do this is shut down VS2005 (unload EntLibConfig and dll(s)) copy the file and start over.
Or
Don't configure VS2005 to use the folder and launch EntLibConfig outside VS2005, but after doing it once and configuring it back I still get the error.
Or What I finally did was made a copy of the bin folder in C:\EntLib3Src\App Blocks\ copy the dll(s) to that folder and then launched EntLibConfig outside VS2005

What I want to know is if my cycle is wrong and I need to do something different so I don't have to either have multiple coppies and/or exit VS2005 each time I make a change?

The ideal thing would be able to unload EntLibConfig from memory inside VS2005 and all the dll(s) including the one I'm working on. Then allow me to re-launch after the deployment of an updated designer?

Funny thing is this goes back to the AppDomain issue with Type Selector.

http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=9640
http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=9240
http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=9345

To me it seams all this Assembly loading and caching is done by magic and trying to shield the user (who are developers btw) instead of bring it to the front end. Even more slick would be an Assembly/Type Selector manager inside EntLibConfig. Instead of unloading EntLibConfig I could unload the assemble by way of putting this in a seperate AppDomain. Then I could from EntLibConfig (instead of magic) control the loading of my providers, etc.... by using an AppDomain manager that would show all the load assemblies that being providers, validators, exception handlers, etc.. Show the full names as well for name idetification issues to resolve the mismatch issues.

I love the product and don't plan on stopping, but if the next release does not have improvements in these areas which where just as bad in EntLib 2.0 one would have to ask "Is Microsoft eating there own dog food?” If I can and other can run into these issue with simplicity what does MS do when you run into them work around them but don't make improvements? I like the fact that new blocks are coming and architectural enhancements are being made, but there could be a barrier to entry because EntLibConfig is flaky at best. Just when I though I got over the Type Selector issue now I run into this. The anaolgy that the internet is great and has a lot of content but if I can't get to it, or it is a pain the *** then what good is it?