Catherine Celeste Scolamiero was born at 8:11pm 1/14/2008, weighing exactly 7 lbs. and 20 in. of length. Everyone remarked at her long and beautiful dark hair. She is doing very well.
Stefanie is also doing well and currently recovering.
Monday, January 14, 2008
Chasing Chad
Chad Myers and his wife recently had a baby, and we're following them right up with one of our own. My wife is currently in labor with our baby and we're blogging to notify our friends and family with updates. The internet is a wonderful thing!
Thursday, January 10, 2008
The Joys of AppDomains
Problem: We need the ability to launch a .NET executable that has ShadowCopyFiles turned on by default in the AppDomain.CurrentDomain.
This is an issue because, from what I can tell, since .NET 1.0 there has been no way for an assembly to modify the settings in the primary AppDomain. The last time I looked at this issue was back in 2004 when Bob Aman and I did some serious work on dynamically loading/unloading AppDomains on the fly. We enabled ShadowCopyFiles on the created AppDomains so we could update the assemblies loaded on the fly as well. Delving into these depths of the CLR and Fusion turned out to be a major undertaking as we had to slog through one of the most poorly documented portions in all of .NET. In the end we were able to work it out and everything came together.
Solution: This time out, three versions of the .NET framework later, I was seriously disappointed to see how little this area has improved. Again it was back to the answer-less message boards and Google groups to try and scrounge up an answer. Fortunately instead of being several months worth of work it was only a few days before I was able to find an answer: Create a launcher executable so simple that it is extremely unlikely to ever change then have that executable create a new AppDomain with ShadowCopyFiles enabled. The launcher will then run.ExecuteAssembly() on the executable we want to have ShadowCopyFiles enabled.
Pros: The portion that we really want to be modifiable will be. Also the solution is pretty elegant as the launcher is reusable anytime we run into this particular situation.
Cons: This solution is really just a work-around (a kludge in the eyes of some) because we can't really change the settings on the default AppDomain a process gets. The launcher won't be modifiable at runtime, so it's really important that it's extremely simple and unlikely to change.
Sources: Here's a list of a few places with helpful information on this problem and related problems.
This is an issue because, from what I can tell, since .NET 1.0 there has been no way for an assembly to modify the settings in the primary AppDomain. The last time I looked at this issue was back in 2004 when Bob Aman and I did some serious work on dynamically loading/unloading AppDomains on the fly. We enabled ShadowCopyFiles on the created AppDomains so we could update the assemblies loaded on the fly as well. Delving into these depths of the CLR and Fusion turned out to be a major undertaking as we had to slog through one of the most poorly documented portions in all of .NET. In the end we were able to work it out and everything came together.
Solution: This time out, three versions of the .NET framework later, I was seriously disappointed to see how little this area has improved. Again it was back to the answer-less message boards and Google groups to try and scrounge up an answer. Fortunately instead of being several months worth of work it was only a few days before I was able to find an answer: Create a launcher executable so simple that it is extremely unlikely to ever change then have that executable create a new AppDomain with ShadowCopyFiles enabled. The launcher will then run
Pros: The portion that we really want to be modifiable will be. Also the solution is pretty elegant as the launcher is reusable anytime we run into this particular situation.
Cons: This solution is really just a work-around (a kludge in the eyes of some) because we can't really change the settings on the default AppDomain a process gets. The launcher won't be modifiable at runtime, so it's really important that it's extremely simple and unlikely to change.
Sources: Here's a list of a few places with helpful information on this problem and related problems.
- How to Set ShadowCopyFiles for CurrentDomain - This is a post that describes the same problem I was trying to solve. There weren't really any helpful answers posted here, however it does have some discussion of the problem.
- Get rid of EXE/DLL locks by using ShadowCopyFiles appropriately - This post has some excellent sample code for the Launcher.exe. It's a bit hard to read at some points.
- AppDomain Shadow Copy Explained - A great treatment of the ShadowCopyFile basics by Bart De Smet.
- Plug-in Manager - The article on fully dynamic plug-ins by Bob Aman back in 2004. This documents several lesser known quirks of the AppDomain system and contains some great explinations for the way the whole process works.
- AppDomain and Shadow Copy - A blog entry by Microsoft's Junfeng Zhang that captures some of the ShadowCopyFile quirks. It's important to note that the API calls he mentions at the end have all been depricated and SHOULD NOT be used.
- AppDomain Question - An expert discussion of the particular problem faced here and suggestions of alternative ways to solve it. An excellent source for information.
Tuesday, January 08, 2008
Welcome Back
I know it's been over a year since I last posted here, but I am back, and look forward to blogging some more. It's good to be back, and I can't want to post some new content dealing with the 3.5 framework and VS2008. There will definitely be more to come soon, in the meantime check out a new blog I've added to my must read list:
Chad Myers' Blog - RSS
Chad Myers' Blog - RSS
Subscribe to:
Posts (Atom)