.NET

Simon Guest Leads The Architecture Journal

Michael Flanakin — Mon, 27 Feb 2006 09:37:00 GMT

The Architecture Journal just reached it's sixth edition. Fantastic! I've anticipated each edition and welcomed the dedication Microsoft has started to focus on architecture, design patterns, and best practices. That's one area where Microsoft development organizations have fallen short. The lack of guidance has stifled the community's growth a lot, in my opinion. The ease of VB classic definitely helped make up for this in the big picture, but standardized development with promising guidance has never been so available. I'm lovin' it! (Nobody tell McDonald's I said that - it's their current slogan.)

With their sixth release, a very nice turn of events has taken place. Microsoft has decided to transition the magazine to a permanent staff - as opposed to the temporary, "test-bed" staff that's been getting it up and running. To lead this group, Simon Guest has been recruited (to that team, anyway - he's already a Microsoft employee).

Simon is a great asset to this team. I was lucky enough to hear him speak and discuss a few topics with him a few years back at an architecture conference for government customers. One of the best things about Simon is his J2EE experience. The J2EE community has had more of a focus on architecture, design patterns, and best practices than the Microsoft development community has. Simon uses this experience to focus .NET development in the right direction. I know that The Architecture Journal will just keep getting better and better - not to take away from its current success.

So, I think I can speak for all .NET software architects when I say, "Welcome, Simon! We expect great things in the road ahead and are excited to see what the new team churns out." Architecture is a very important discussion topic and as someone with has interop at the top of their priorities, Simon will serve this task - and us - well.

UpdateVersion 1.3 Available for Download (...finally)

Michael Flanakin — Wed, 18 Jan 2006 15:49:00 GMT

I was finally able to get UpdateVersion 1.3 available to the public. If anyone does any work on it, please let me know. I thought about setting up a project for it, but there haven't been any big feature requests, so I decided against it. Hope you all find it useful!

Update (4/4/2008): Switched to new link on CodePlex.

First (and Second) Webcast

Michael Flanakin — Wed, 18 Jan 2006 14:52:00 GMT

Well, I actually participated in my first webcast yesterday. Brian Scarbeau invited me to join in on his 3rd DotNetNuke webcast on custom module development to help by answer questions and filling in as needed. It went quite well and I plan on also participating in his 5th webcast on skinning. Should be interesting! If you're interested in DNN skinning, I suggest you check it out.

Generating Empty Alternate Text for asp:Image Controls

Michael Flanakin — Fri, 06 Jan 2006 12:45:00 GMT

As I'm sure you already know, one of the accessibility standards Section 508 covers is specifying alternate text for all images. Not a big deal, right? Well, what about images that are purely used for formatting, such as spacers? Well, just give it an empty string: <img src="spacer.gif" alt="" />. Ok, still not a big deal. Unfortunately, the Image control in ASP.NET 1.x only outputs alternate text if it contains a value. For instance, <asp:Image id="spacer1" ImageUrl="spacer.gif" AlternateText="" runat="server" /> does not render the alternate text. Instead, this is the output: <img src="spacer.gif" />. The only way to add an empty alternate text string is to do it programmatically: spacer1.Attributes.Add("alt", "").

ASP.NET 2.0 hit the streets with a new lease on life. The goal was to be more standards compliant. Every control has been changed to support XHTML standards in three modes: legacy (HTML 4.0), transitional (XHTML 1.0 Transitional), and strict (XHTML 1.0 Strict). Apparently, using legacy conformance will not render your tags in an XHTML-compliant manner, which I think is kind of stupid, but oh well. Anyway, back to the matter at hand... The new Image control adds a GenerateEmptyAlternateText property. As the name implies, this will give you the empty alternate text, but only if you set it to true. What's up with that!? Ok, I realize that this is kind of a small issue; but if you're so stuck on standards compliance - which I'm happy about, by the way - why not just automatically output empty alternate text if no alternate text is specified? I don't really have a problem with the GenerateEmptyAlternateText property, just give it a default of true. Heck, even if you only do it for transitional and strict modes, it'd still be nice - not that this has anything to do with XHTML conformance.

DotNetNuke Image Module Project

Michael Flanakin — Thu, 05 Jan 2006 13:58:00 GMT

Well, I've been very busy over the past few months. Project after project at home and work. Well, I definitely made sure to get my all-important playtime at home, too, of course. I guess it's all a good thing, tho. I just haven't had too much time for new posts. I do have news, tho. I was just added to the DNN Image Module Project last week. I just got the latest code and plan on adding some of my own updates to it within the next week or so. I look forward to contributing. There aren't too many items in the issue tracker, but I have seen some in the project forums. I'll try to start getting issues in and being productive soon. It should be fun.

DNN and the Lovely "Multiple controls with the same ID" Error

Michael Flanakin — Fri, 25 Nov 2005 15:58:00 GMT

After having this problem several times and continually forgetting the fix, I figured I'd go ahead and make a post about it. Hopefully, it'll save someone time in the future. Let me know if you have a different fix.

Symptoms

When you browse to a DNN page after adding a new module to the page, you receive an error message that is similar to the following:

Multiple controls with the same ID 'ctr123_DD' were found. FindControl requires that controls have unique IDs.

Cause

DNN dynamically loads modules to the page when it loads and references them using the Control.FindControl() method. As the error specifies, FindControl() can only be used when all IDs are unique. This usually happens when a module definition has been recently modified. DNN modules are identified using a combination of the key and type properties. To specify the control that should be loaded when a user browses to a page with the module, the key should be blank and the type should be "View". The default edit control (i.e. Add content) and the settings controls should have key values of "Edit" and "Settings", respectively. All other controls need to have unique key values. When non-unique key values are used, DNN loads all of the controls with the same ID, which is the true culprit.

Resolution

First, you'll have to know what module is causing the problem. If you are unsure of which module is causing the problem, there are three ways to figure it out:

If a module was just added to the page before the error occurred, the module that was added is most likely the problem. (Cause you needed me to tell you that, right?)
If a module on the page that's giving you the error was just added, that module is most likely causing the error. (Another great hint!)
If neither of the previous identification methods work, the module ID is listed in the error. "ctr123_DD" refers to module 123. Take a look in the dnn_Modules table and the row with that ModuleId is definitely the problem.

After finding the offending module, browse to the module definitions page (Host > Module Definitions) and check to ensure all module controls have unique key values. Remember: default view is blank, default edit is "Edit", settings is "Settings", and all others can be whatever makes your little heart go pitter-patter. Once the key values are corrected, you will most likely have to restart IIS. The quickest way to do this is to use iisreset (Start > Run, type iisreset, click OK).

More Information

Applies to: DotNetNuke 1.0 - 3.1 (I don't think it's been fixed in newer releases, yet; but I haven't confirmed anything newer than 3.1)
There is another error that does not specify the module ID, "Multiple controls with the same ID 'ctr' were found." This fix does not apply to those. If/when I run into that one again, I'll try to post a fix on that, too.
I may have found the cause of the 'ctr' error. It seems that this is caused with malformed HTML within the ASCX and/or mis-matched assembly (I didn't notice there was a build error because VS was saying it built successfully, for some reason.) This happened right after editing a module control, so I just opened the ASCX file in the designer and solved the problem pretty easily. I'm pretty sure this also happened when I wasn't customizing a control, but I can't really remember. That's all I really have right now. Hope it helps someone.

VSZ File Parameters

Michael Flanakin — Thu, 27 Oct 2005 09:52:00 GMT

I'm working on a couple Visual Studio project wizards and have been looking all over the place for a list of VSZ parameters. Well, I finally found the list here: http://msdn.microsoft.com/library/en-us/vccore/html/vclrfpredefinedcustomwizardsymbols.asp. Just figured I'd post it here in case anyone else was looking for it or I needed it again in the future.

One side note, however: VS05 wizards are a LOT easier to create and manage. I'm definitely looking forward to those. They're require a complete change of current wizards, but it should be well worth it.

VB Angst

Michael Flanakin — Thu, 15 Sep 2005 12:22:00 GMT

Ya know, I'm not trying to start any holy wars or anything, but I keep getting aggravated with some VB code I have to maintain.

First off, my biggest complaint is the way VB handles imports. A lot are assumed, but some aren't. I've even seen the same code transition to another machine and have it not work. I don't really know the rules behind it, but it sucks.

Second, the Microsoft.VisualBasic namespace needs to just die a horrible death. Do VB-ers not understand that it simply exists for backwards compatability and shouldn't be used? Sure, you may have the old VB6 functions around, but should you use them? NO! There's a reason it's in Microsoft.VisualBasic and not in the core .NET base class library!

While we're on "functions," let me gripe about the naming conventions. I understand the difference between a subroutine and a function - who doesn't? I just don't like the fact that they are different from the .NET standard of "method." Yeah, yeah, backwards compatibility, whatever. Backwards compatibility is the root of a lot of evils in the software world. Look at Java. One of the primary reasons it sucks so bad and doesn't go thru a major overhaul is because of backwards compatibility. Other things I don't like as far as standard naming goes are the keywords Shared, Nothing, Me, and so on.

This is a small one, but I hate the fact that Visual Studio doesn't tab regions in for VB. I like my regions to be tabbed in at the same level as the code. This is just a preference, but I think the code seems harder to read when the left edge of the code jumps back to the first character position every so often. As a matter of fact, Visual Studio's auto-formatting for VB drives me crazy altogether. Most of it works fine; but occasionally, I want something to look different for readability concerns. I'm sure there might be options for this, but I don't care enough to look. It's just annoying.

Speaking of readability, OMG!!! Nobody can argue that VB is more wordy. One thing I learned in a high school desktop publishing class was that white space is good. White space actually helps the brain process what's on the screen and separate code easier. It's a LOT harder to do that with VB because the lines can get so long and seem to jumble together. Granted, this only happens in lines with a lot of keywords, but that doesn't mean I like it any more.

Oh, great, now it's time for my favorite (well, for the past two days, anyway): modules. I've been working on .NET since its inception. I cheered on C# and revelled in its birth. Because of that, I ignored VB and its features (in part, that's why I'm getting so aggravated). Well, for the past few days, I copied some VB code and was modifying it. I kept looking for what seemed to be local methods, but couldn't find them anywhere. I searched through class after class to no avail. Finally, I was looking at an assembly and noticed that a class was using the Module keyword. "Hmm... That's odd. I wonder what that is. Oh well," I thought. A little later, I ran into another method I couldn't find anywhere. Then I made the connection and found it. This has got to be the most retarded feature. I can understand and appreciate it's worth, but I just don't like it. It obviously decreases readability and maintainability. Oh, and before you say that I should've used the "Go to Definition" context menu option, I didn't have the source loaded in a VS project, so I couldn't.

I don't even need to get into the obvious ones like case-insensitivity and Option Strict/Explicit. Hell, I think I've complained enough for today. There are a ton of other things I don't like about it, but this'll suffice. Also, I must say that I am merely pointing out my angst with VB. I am not saying that C# or any other language is perfect. There are aspects of VB I'd love to see in C#.

Merge Assemblies

Michael Flanakin — Fri, 19 Aug 2005 13:57:00 GMT

OMG!!! This is absolutely sweet! Granted, I haven't used it, but the prospect is awesome. With ILMerge a developer can combine multiple .NET assemblies into one. I guess the main reason I'm so excited by this is because I've done a lot of work with reuse libraries. I tend to break those out into core, web forms, windows forms, web services, and security libraries (among others) similar to how .NET is broken up. Due to this, people may have to copy 4 or 5 assemblies just to get the features they want. With ILMerge, they can all be managed together (since they're all part of one repository, anyway). So, by using ILMerge, developers have the choice to have one or five assemblies, depending on the capabilities they need to implement.

The only thing I wonder is how this might effect internal code (code that can be only accessed within the assembly). I'm sure I'll get a chance to test it out sooner or later. I honestly can't wait!

abstract override

Michael Flanakin — Wed, 10 Aug 2005 08:54:00 GMT

Mike Stall posts an interesting bit about the abstract override keyword combination. I thought this was very creative. It's always great when someone is able to think outside the box and see things in a new way.