Tuesday, August 6, 2013
Here are a couple examples:
And default styling with no line numbers:
The question came up last week about swapping out an MEF enabled DLL on the fly. Because .NET locks the assembly even in an MEF enabled application, you can't replace the DLL when you release the MEF parts in your code. The only way to replace a DLL without a little elbow grease, is to shut down the application, swap out the DLL, and then restart the application. So, after researching and finding a couple of decent examples and after applying the elbow grease, I came up with this solution. It's not pretty and it doesn't do much except prove how to do this. This is a copy of my Code Project article of the same title.
This example will only work with .NET 4.5 and above and assumes you already have an understanding of how MEF works and can get around with it without going into a tutorial on that.
We will be using the AppDomain class to create an application domain for the MEF components to run in. This will allow us to access the components at run time. I'll explain more of what's going on as we progress.
First, create a console application project called AppDomainTest. And in your
Program class. I have a couple of paths set up here that point to where the MEF DLLs are found and where the AppDomainSetup will cache the DLLs while running. I'll explain more of that later.
Now, create a class library project called AppDomainTestInterfaces. This library will contain the contract interface for the MEF libraries and the main application. Add a reference to this library in the main application. Delete the class file in there and create an interface called IExport.
Next, create a couple of MEF class library projects. Add references to AppDomainTestInterfaces and System.ComponentModel.Composition in each library.
You'll want to set the build output to the bin\debug folder for the main application as shown. I put the compiled DLLs into a folder called Plugins under the main application bin\Debug folder so that they were easy to find and I could set up my code to be simple for this example. Use your own folder as needed.
Finally, create a class library project called AppDomainTestRunner and set a reference to it in the main application. Add references to System.ComponentModel.Composition, System.ComponentModel.Composition.Registration, and System.Reflection.Context to add access to the necessary MEF components used in the rest of the example. And lastly, add a reference to AppDomainTestInterfaces.
Now we can get to the meat of this project.
AppDomainTestRunnerlibrary project, delete the Class1file and add a Runnerclass. This is the class that will deal with the MEF imports and exports, and we will see that the entire class runs in a separate AppDomain.
Next, set up the MEF library code as shown below. This just shows that we actually are running in the DLLs. I created two of the exact same libraries, just naming the second AppDomainTestLib2.
Note the use of MarshalByRefObject, this will, in essence, mark this class as Serializable and enables access to objects across AppDomain boundaries, thereby gaining necessary access to methods and properties in the class residing in the hosted AppDomain.
Finally, set up the Main() method as follows. What we see here is the use of an AppDomainSetup object to define our AppDomain configuration. This establishes the shadow copying of the DLLs and where to shadow copy to. The CachePath parameter is optional, and only shown here as proof of what is happening. The parameter ShadowCopyFiles is a string parameter and accepts "true" or "false". The ShadowCopyDirectories parameter establishes which directory to shadow copy from.
About shadow copying: ShadowCopyFiles will take a copy of the DLLs that are actually used in the AppDomain and put them in a special folder then reference them from there. This allows the DLL in the Plugins (or any other configured folder) to be deleted or replaced during runtime. The original DLL will remain in the folder until either the next startup of the application or, in the example we will see, the DirectoryCatalog is refreshed and the CompositionContainer is recomposed and re-exported.
Now, when you run the application, you see the MEF DLLs run and within "Host_AppDomain".
At this point, you can go into the Plugins folder and delete a DLL then press any key in the console window to see what happens when runner.Recompose() is called. We then get proof that the recompose released our DLL, but only because of the ShadowCopyFiles parameter.
Now, open another instance of Visual Studio and create a class library called AppDomainTestLib3. Add the same references as before and don't set the output directory, we'll want to copy that in by hand. Set up its Import class code just the same as the previous AppDomainTestLib classes. Go ahead and compile it.
Next, run the application in the previous Visual Studio instance and stop at the first Console.ReadKey(). Delete a DLL from the Plugins folder and copy the new one in place. Press any key to continue...
Pretty cool, eh?
Finally, to actually replace a DLL, you must delete the previous DLL prior to implementing the new one. We can demonstrate the manual way of doing this by inserting the following code into Program.
Leave the current AppDomainTestLib3 in the Plugins folder and run the application. Now, follow the prompts and when you get to "Here we will begin to replace Lib3 with an updated version.", make an observable change to the AppDomainTestLib3 and compile it. After completing the deletion of the old DLL, press any key to recompose the DLLs. Now, when you get the next prompt, drop the new DLL into the Plugins folder. Hit any key as usual. You should now see the response from your changed DLL.
The reason for the double runner.Recompose()calls is that the Exports signature for the DLL matches the previous version and MEF doesn't see a change since it doesn't look at FileInfo for differences. This then tells the AppDomain that the DLL hasn't changed either and the ShadowCopyFiles doesn't kick in to make that change. The simple work around is to delete the original, recompose, put the new one in place, and recompose one more time. The only disadvantage I can see in this is the performance of the application will drop momentarily during the recompose.
I've added a Github repository with the source. I also included in that source the ability to pass data between AppDomains. The source can be downloaded from http://github.com/johnmbaughman/MEFInAnAppDomain.
Thursday, February 10, 2011
Update: You can download it here on GitHub: http://github.com/johnmbaughman/UnhandledException
Tuesday, September 28, 2010
Friday, October 10, 2008
Wednesday, July 23, 2008
To do all of this, I need to be able to call the methods dynamically using Reflection.
In my application, I use a criteria (or request) object to pass in parameters to the method and a response object on the return. So, here are those objects:
Next up, we have our class which has the method we are going to call.
Finally, our method to process our dynamic call.
I hope this little sample helps someone else in their struggle to dynamically call code in .NET. Translation to VB shouldn't be too difficult. And as far as I know, this should work in all versions of .NET from 1.0 to 3.5.
Friday, June 6, 2008
I've seen a few sites mentioning techniques for debugging within a Siteminder world.
This may be a little out dated since it uses Visual Studio 2003, but I'm pretty sure the technique is the same.
Without further ado, here's the steps to do debugging:
- Make sure Visual Studio is not running. It's not mandatory, but it makes it an easier approach.
- Disable Siteminder. This is usually done via config file called WebAgent.conf and is generally located in C:\Program Files\netegrity\webagent\bin\IIS\. Look for a line that looks like EnableWebAgent="YES". Change "YES" to "NO". Note: Case is VERY important!
- Restart IIS. Normally, this is done through the IIS management console, but a reboot will also work. However, that approach won't work later on.
- Start your Visual Studio instance and your Siteminder protected project.
- Next, after the project has fully loaded, change the "NO" back to "YES" and restart IIS. (See why rebooting doesn't work?)
- Now, debug using "Attach to process" and attach to the ASP.NET worker process for your Windows version.
This is a rather simplistic approach, but it works very effectively. It's a pain, but once you get used to it, it becomes second nature. One of these days, I'd like to write a script that automates this, but for now I'll settle for the extra manual steps.
In VS 2008, most of these steps are not needed. In particular, steps 1 through 5 are not needed, You just need to make sure that Siteminder is enabled and you attach to the ASP.NET worker process running through IIS. This will not work in the "built in" web server in VS 2008.