November 2003 - Posts
The Object Model Generator (henceforth referred to as OMG) is a tool designed to provide the programmer with a simple code generator able of transforming XML Schema Documents (XSD) into a Typed Document Object Model, using either C# or VB.NET as a language.
The tool is currently in Preview Version (which is sort of a beta version), and features the following:
- Typed Elements (incl. simple elements).
- Typed Attributes.
- Attribute Nullability (incl. Value Type Nullability).
- Typed Complex Elements (Sequence, Choice).
- Attribute Change Events.
- Typed Sub Element Search By Attribute.
- Load From / Save To XML (incl. verification against original schema).
Please note that the application does not support XSD Simple or Complex Types at the moment.
The program is freeware and my only wish is that you tell me if it helped you in any way or if you generally think it's cool...
[ Update: I have created a page for my projects, including one for OMG. ]
Microsoft has placed everything PDC, here.
I'll be scouring the place this weekend for anything useful.
[ Update: Not via Jeff Key, but worth noting. ;) ]
Sorry for not updating for long. I was abroad for a week and quite busy with paying and some not paying work related issues the rest of the time.
There's also something to be expected soon. As many a blogger has done before me, I am also going to release a useful tool. Stay tuned.
It's annoying to have a DLL in Debug mode that you had another team make and give you their source with it, but not be able to debug into it without adding the source project to your solution and using a Project Reference.
Who said you couldn't?
AmiD has come up with a simple way that allows you to debug into the source of file references:
- Take the PDB file that was created in your bin\Debug directory and place it in the same directory as the compiled Assembly (if it's in the GAC, you'll have to place it in the same directory as the version that is in the GAC; usually %WINDIR%\assembly\GAC\%Assembly Name%\%Version%).
- Take the solution referencing the Assembly file and delete its .SUO file. This file saves Visual Studio.NET's configuration (Breakpoints, Open Document Windows, etc.).
- Go to where you want to Debug Into (F11) the Assembly, press F11 and a dialog would appear asking you where the source files are. This selection can only be made once (unless you re-delete the SUO file).
This allows you to Debug into File References, provided you have the source files.
As .NET languages don't have friendship (or anything in the vicinity), the Internal modifier has come into play.
I had a conversation about this with AmiD a while back and we came to the conclusion that we need a new access modifier, since Internal is too limited (we have to create our own unexposed assembly to assembly interop).
So here I am suggesting the Trusted modifier. This modifier will be checked not against containment in the same Assembly, but against having the same strong name.
What does this mean?
It means that if I have two assemblies, let's say:
Omer.A, Version=, Culture=, PublicKeyToken=b03f5f7f11d50a3a
Omer.B, Version=, Culture=, PublicKeyToken=b03f5f7f11d50a3a
(Note that both Assemblies are signed with the same key)
Using the Internal modifier on a member in Assembly Omer.A, I could access it from anywhere in the same Assembly.
Using the Trusted modifier on a member in Assembly Omer.A, I could access it from anywhere in both Assembly Omer.A and Assembly Omer.B, since they share the key.
I think this to be extremely useful, especially for application suites created by the same manufacturer.
Update: Paul Wilson has informed me that this already exists in the form of an attribute. I still think it would be best if this was part of the .NET languages.
Update: Jim Hogg explains in the comments about a new feature, Friend Assemblies, and catches lots of people's attention.
Been going over the PDC slides and got to TLS321: Visual C# “Whidbey” - IDE Enhancements For C# Developers and TLS320: Visual C# "Whidbey": Language Enhancements. As far as I can see, next year I'll be getting some new toys.
Cool: Filtered Auto Completion - If you write a catch phrase, the list of autocomplete options will filter to classes that inherit from System.Exception.
Cool: Find All References - Just like Find In Files, but for references.
Cool: Automatic Property Creation for Field - Finally! Thank you, Whidbey Team!
Cool: In house refactoring - Now all of your little "This doesn't look good enough" tasks are done automatically.
Cool: Generics, Iterators, Partial Types. I predict Anonymous Methods to be a nuisance.
Cool: Property Accessor Accessibility - Being able to further restrict a certain accessor for a property (get is public, set is internal, etc.).
Uncool: Excessive use of the bold font.
Uncool: Namespace alias qualifier. It seems as though Microsoft decided that instead of trying to work out the problem of namespace
name/namespace name and namespace name/class name collisions, they would simply work around it. Maybe it's just me, but I expected more from Microsoft on solving such an annoying and foolish problem.
...and yes. I am posting this at 4 o'clock in the morning.