She's Here!

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.

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!

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.

• 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.

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

Snow and happiness

Merry Christmas everyone!

A good story

I recently had a slowness issue keeping my old project from going into full BETA. The issue would show up on Windows 2k3, however not on XP Pro. Essentially what was happening was that a certain page in the project was taking 9 - 30 seconds to load with small amounts of data (between 30 and 100 records), obviously an unacceptable amount of time. Trace.axd revealed that the page itself was loading and processing in ~.12 seconds, however it was taking the rest of the time to render. This was a big deal, and beyond the scope of my code to debug, so I decided to get a little backup from Microsoft to find out why there was such a huge discrepency between Win XP and Win 2k3, as well as what was taking so long in the pre-render through rendering phases. Well three days later we found that the issue was within one of our component vendor's controls (we use DevExpress), and specifically the licensing call. As it turns out the licensing call was being made recursively every time the page was hit. This execution "explosion" was the cause of our problems. So we contacted DevExpress, provided them with all of Microsoft's data and our own data (traces, dumps, etc.), and to our surprise we were given a bit of a run around by their support people.

At this point things look bleak (vendor giving you the run around with a critical piece of software), however all was not lost. The hero of the story on the DevExpress side would be their CTO: Julian. We contacted him with our troubles, he got to the bottom of it, we received a release fixing the licensing issue, and we were informed that in the future they would be rewriting the component in question in order to fully optimize it for speed. So in the end everyone was a winner, I have a product well on the way to production, DevExpress really came through for us (all is definitely forgiven there!), and all DevExpress users will probably be very impressed with their performance in the 6.3 release.

How hard can it be people?!?

Alright, you have .NET, you have ORACLE, and you have LOB fields (BLOB/CLOB, i.e. a place to store huge amounts of data for anything (BLOB) or for up to 4GB of text (CLOB) for those who don't know). How hard can it be to make a relatively coherant set of simple conversions, particularly for things over 32kb in size?!?! Obviously it isn't easy, or we wouldn't have to go through all of this mess. Needless to say I'm more than a little ticked off at both Microsoft and ORACLE on this one. It should be pretty normal to allow people to store things like files, images, and large strings on the database, and we've been doing it for years. So why does it have to be so hard to do? Why can't we just have a simple conversion from the .NET type to the ORACLE parameter? Why isn't there a simple way for us to pass BLOB parameters in .NET? It's time to get on the ball over there at ORACLE and Microsoft; give us a good solution.

Updates, DevExpress, Licensing, etc.

First of all I want to apologize for it being so long since I've updated. Work's been crazily busy, and the last thing I've had time for is updating blog entries. I would, however, like to post on a couple of things.

First a heads up. If you are currently working with DevExpress controls there may be a problem in Windows 2003 Server with their ASPxGrid's licensing call. I've noticed this with the site I'm building and when hosted on Win2k3 it takes almost three times longer to complete rendering of the grid on the server side. This issue may affect all their controls as well. I am currently working on that with their support team and Microsoft. If this is really a problem I'll post about it again and let you know.

Also, speaking of DevExpress, I actually tried what was described in this post and I have to say, Julian B, you rock! He actually took the time to talk to me and I believe him that the performance issues I've discussed will be looked into and resolved. Again, huge kudos to Julian. DevExpress is a good company, and though I have some issues with their controls (VS2k5 documentation) I am consistantly impressed by their commitment to customers. In other words, buy their stuff.

Okay, now for some cross posting blog mentions:
-Joe Duffy: When you have one too many threads, or want to do multi-AppDomain instantiation (say it with me, Rich-Client Plugins) this is the blog for you. I look forward to more cool stuff coming from Joe.
-Junfeng Zhang: This just confuses me sometimes, but it's a good detailed blog about the .NET Framework.
-Mark Russinovich: Mark is here for when Windows just makes you say WTH?
-Chris's Corner: Want some Vista hate? Go here, and not only learn what to hate about Vista but also why, when, and how much.
-Tom Hollander: Wow, I mean just wow. The P&P folks are the best at Microsoft. They're actually making things that are causing enterprise level development to be better, easier, and cheaper. Who would have thought? Power to the people Tom, power to the people.
-Peter Bromberg: Who is this guy and why does he rock so much? I dunno, but keep up the good fight Pete. He's a great dose of humor, politics, and in your face programming. If the code doesn't work Peter will beat you and your code until it does, and you'll like it!

Alright, that's it for now.

100% Pure MicroLive

I know it's been awhile, and I'm sorry about that.

Lately I've been checking out the "Live Revolution" over at www.live.com to figure out what all the buzz is about and to keep tabs on where The Borg are going technology wise for the more main-stream. This, scarily enough, lead me to create a "LiveSpaces" site (currently MSN Spaces, but that will change just like messanger I'm sure).

Now the more I think about this Live stuff, especially in light of Verizon's FiOS initiative I am slowly becoming convinced of a new web revolution, one where some of our old web-dreams will come true. In particular I think that the web will become a very likely place for very rich-client style apps and maybe even a host for XAML/AJAX apps with full rich client functionality available without the pain of Flash and the postbacks of server-side code. Who knows, this may lead to even more unstructured work environment possibilities, though I get the feeling that Europe, Japan, and possibly Austrailia are already there (please comment to me and let me know if they are). Anyways, I don't know whether or not these will be realities until my generation becomes management, however the idea of "flex-work" instead of just "flex-time" seems to answer some of the slave to the job via technology issues of today. Though I think about management, and they just won't want to give up control. It's an intersting though though.

Anyways, let me know what you think.

Some quick pondering

After a conversation this weekend with a friend, I thought I might post some useful links for those going down a service or component oriented route. I hope these are helpful.

-Microsoft's Enterprise Library for .NET 2.0: The Enterprise Library's latest version is a really wonderful framework for the development of both Applications and Services. In summary it is divided up into six distinct Application blocks designed to cover basic abstraction that are also open source. Some of the most useful blocks are the Data Access Application Block (DAAB) and the Cryptography Application Block (CAB). Look for more and more pieces to be added to this block in the future. Also, if you are looking to develop applications for Oracle and use the DAAB you should read this blog further to see some interesting issues and hiccups you may run into. The DAAB is also great if you need to develop for several databases and need the .NET implementation side to be close to database agnostic. That being said this may be impossible with Oracle due to their seeming inability to work cleaning with a generic implementation.

-ODP.NET and ODT for VS2005: Though still in Beta, this release looks to be feature complete, and reasonably stable enough. Though Microsoft and Oracle will still bicker about smaller details it is still better to use the Oracle provider than the one included with .NET by default. The Oracle implementation is faster, more flexible, and will provide better integration than the standard .NET provider. It is also possible to modify the DAAB to use ODP.NET instead of the default .NET provider. I would also like to mention that the code changes for the DAAB are relatively minor (shouldn't take more than 30 minutes if you know what to change before hand).

-Ingenious MVC: By now all developers should be trying to learn and get used to patterns. One of the most powerful patterns available is the Model-View-Controller (MVC). Though a discussion of that pattern is out of scope for this post, I would strongly encourage reading Chapter 14 of Martin Fowler's "Patterns of Enterprise Application Architecture". It is important to note that MVC is not just for Web Applications, it has plenty of application for rich client applications and should be included at the application form level (i.e. forms have controllers specifically developed for the application they are in, or the purpose they serve, controllers should not be "super-generic" for any/all applications). That being said my friend Kent Boogaart has developed an excellent MVC framework that is extremely straight forward and easy to implement. The base documentation for Ingenious MVC is very good, however it's usage documentation is not yet complete. I would suggest reading the documentation for Microsoft's User Interface Process Application Block (UIPAB) (and here) if you would like further information, however you should not use Microsoft's block as it is going to be replaced in approx. 1 - 2 years for .NET 2.0 and is extremely complicated. You should use Kent's framework instead as it is a simplified version of the UIPAB and is much more clean and consistent. I have full confidence that Kent's Ingenious MVC will be well supported and relevant in the future.

Anyways, that's a good start, and if any of you out there have any questions, please feel free to comment, and I will be happy to respond as I can.