November 2005 - Posts
I've been relatively quiet the past few months... in case some of you were wondering,
here's why.
Yesterday, I posted about needing to be able to track changes to generic collections. I've been diving really hard-core into CodeSmith, and right now I'm working on a set of templates that will generate an entire provider model-based website architecture from a set of database tables.
I know some people are going to suggest programs like LLBLGenPro or WilsonOrMapper... but I've never liked the architecture of either system. I wanted to go back to the attribute-based serialization framework from XHEO, but they're not releasing it anymore, so it's unsupported. So instead of trying to learn a new model for this down-and-dirty prototype, I decided to roll my own system.
But I digress. Anyways, in order to simplify the process of saving information to the database, I needed to be able to know which parent and children items had been added or removed. That way, I could call ParentManager.Save(Parent), and if any child objects have been added, removed, or changed, they'd be saved automagically as well.
Enter SmartList. I call it a compound collection, because it contains two additional internal Lists. One contains all the added items, one contains all the removed ones. So, I can use it as follows:
Dim list As New SmartList(Of String)(False)
list.Add("test1")
list.Add("test2")
list.Add("test3")
list.TrackChanges = True
list.Remove("test2")
Response.Write(list.ToString())
Adding (False) to the constructor tells the SmartList not to track any changes to the generic collection. This is so you can load it up with data, and then give it a simple "state" saying it's loaded.
Below is the output from the above code:
Removed: test2 Items: test1 test3
It's probably not the best implementation in the world, but it works well and is relatively performant. I tried digging into List with Reflector, and creating my own internal array structures, but it just got too complicated for my liking. Using two additional Lists did the trick.
You can download the source code here. If you guys have any improvements, please let me know.
I'm writing an app that makes heavy use of Generic collections, and I'm needing to keep track of objects that are added or deleted. Is there a built-in object that supports this already? I'm about 3/4 of the way finished with my own inherited class that does the trick, but I wanted to throw it out there, in case I'm wasting my time. Thanks guys!
UPDATE: I was up late last night writing some great code that totally does the trick, I'll post it as soon as I'm done commenting it all out.
Anyone hear of any firms doing it yet? If not, someone should be. I'd sign up for sure.
Microsoft officially announced today that they will unofficially support MSBuild compiling to the .NET Framework 1.1. Called MSBee (the MSBuild Everett Environment), this tool will consist of new .targets files and MSBuild Tasks to round out the feature set that I had been supporting with previous versions of my kit.
This new package from Microsoft will fix the following limitations of my .targets files:
- Resolving COM References
- Generating resources
- Resolving .NET version-specific managed references
Therefore, there is no need to continue adding this functionality to my Toolkit. Instead, I'm still going to finish my redesign of the Visual Studio 2005 add-in, and see if I can't add some other MSBuild-related features to it. With Craig's help, I'm going to make sure that my add-in not only supports their .targets files, but makes the process of including them in VS2005 projects dirt simple.
Just so you know, I'm also waiting for Microsoft to finish the "Web Deployment Project" VS2005 template, so that my add-in can tie it and MSBee together to compile web applications to .NET 1.1. With these three components tied together, Visual Studio 2005 should be a LOT more powerful.
As soon as I have it wrapped up, I'll push it out the door. Thanks for your patience :)
For everyone that's been asking, don't install the last build on ANY version of VS2005 other than Beta 2. I'm working on a new version for the RTM version that handles Targets much differently. The only problem is, the MSBuild team refactored the MSBuild APIs, which they said were going to help. It didn't even come close. The RTM version actually has less of the functionality that I needed exposed as public methods, not more. So right now I'm trying to set a gameplan for how best to address it (separate API enhancement that others can use, private inheritance, helper methods... etc) and then I'll be able to wrap it up.
I'm also waiting for word on a couple other things... specifically COM reference generation and that Web Deployment kit that lets you use MSBuild to deploy ASP.NET 2.0 web projects like you could in 1.1. As soon as I have answers to those questions, I can wrap this up.
Thanks for all your interest, and keep watching this space.
More Posts