Robert McLaws: FunWithCoding.NET : .NET Framework 1.1

VisualBlogger Beta 1 This Weekend!

interscape — Thu, 01 Apr 2004 12:48:00 GMT

I'm wrapping up the last features for the first beta of VisualBlogger 2004. Wanted to give a brief status report on where I am at, what features it has, and what features are left to be done before the final release.

Beta 1 Features:

Full WYSIWYG Editing
Raw HTML Editing
Blogging ScratchPad
Post To Mutliple Weblogs
Post To Multiple Weblogs with Categories
Blog Credential Hashing in Local Store
Save Posts
Load Posts
Clipboard Access
Code Formatting
Provider Model-Based
2 BlogProviders
- .Text Simple (SimpleBlogService.asmx)
- .Text 0.95 (AspNetWeblog.asmx and BlogContent.asmx)
Abstracted object model mapped to provider-specific objects
Central Bug Reporting / Feedback System

Final Version Features:

Advanced Post Options (Allow Comments, Page Alias, etc)
Dynamic assessment of available options by provider (CanAllowComments, etc)
8 BlogProviders

.Text Simple (SimpleBlogService.asmx)
.Text 0.95 (AspNetWeblog.asmx and BlogContent.asmx)
.Text 0.96 (DotTextAPI.asmx)
Blogger API
LiveJournal API
MetaWeblogAPI
Movable Type API
Atom API

Dynamic provider substitution/addition at runtime
Edit Existing Posts (Where Available)
Edit Categories (Where Available)
Insert New Categories (Where Available)
Upload Images via FTP
Local Caching of Categories
Saved Entries stored as XML
VS.NET 2002 & 2003 Integration
VS.NET "VisualBlog This Code" right-click option (Code autoformating)
IE "VisualBlog This" right-click option
Automatic backups every 5 minutes
Remote Blog Configuration (Where Available)

Ambitious, to be sure, but completely doable. I'm planning a final release sometime in late April / early May. I wanted to release it along with the other stuff Interscape is doing, but this project needs to take a backseat while we collect some public feedback. I want this to be a really kick-butt tool, and I'm willing to wait a bit for that to happen. Plus, I have some other .Text-related development work that I'll need to focus on for a while, so it works out quite nicely.

I spent tha past 3 days doing a complete overhaul on the organization. I redid all of the namespacing, and gave the Web Service references a predictable taxonomy. Posts are now using objects as intermediate storage units, using heavily modified versions of ScottW's .Text objects. I can honestly say now, that I LOVE programming with collections. I can't wait till I can use Generics. Very exciting. I added some nifty features to the existing Category collections, which let me dump the categoty data into various formats depending on the situation. Using this setup also made implementing the providers a breeze. The combination of typed datasets and the new objects make mapping to provider-specific objects dirt simple.

I have really grown as a developer through this project. I really surprised myself with all the things it can do. It took me weeks to figure out the provider model implementation for GenX.NET (found out weeks later that Microsoft's implementation in Whidbey is very similar), and I implemented it in VisualBlogger in a matter of hours. I already found some serious improvements to the model that will be made for GenX.NET 3.1, and was able to streamline the code for that product even further.

Well, enough rambling. I need to test the "Post To Categories" part of the new provider-based system, so I can go to sleep. Got to start getting ready for the MVP Summit. Looking forward to going back to Microsoft again. This will be my second trip, and I am way excited. More on that later.

VisualBlogger CategoryPost Test #9

interscape — Fri, 26 Mar 2004 01:12:00 GMT

The WinForms adventure continues. The CheckedListBox control has been giving me all sorts of problems. For one thing, if you put one in a TabControlPage, and then switch pages, it doesn't hold its state. It took me a little bit of experimentation, but I came up with the following code to help out:

1    Dim chk1 As New ArrayList

2    Dim chk2 As New ArrayList

3

4#Region " OptionsTabPage.Leave Event Handler "

5

6    Private Sub OptionsTabPage_Leave(ByVal sender As Object, ByVal e As System.EventArgs) 
		Handles OptionsTabPage.Leave

7        chk1.Clear()

8        chk2.Clear()

9        Dim tmpChk1 As CheckedListBox.CheckedIndexCollection = BlogList.CheckedIndices

10        For y As Integer = 0 To tmpChk1.Count - 1

11            chk1.Add(tmpChk1.Item(y))

12        Next

13        Dim tmpChk2 As CheckedListBox.CheckedIndexCollection = CategoryList.CheckedIndices

14        For z As Integer = 0 To tmpChk2.Count - 1

15            chk2.Add(tmpChk2.Item(z))

16        Next

17    End Sub

18#End Region

19

20#Region " Tab Control Page Changed Event "

21

22    Private Sub ViewTabControl_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) 
		Handles ViewTabControl.SelectedIndexChanged

23        Dim currentPage As TabControl = CType(sender, TabControl)

24        Select Case currentPage.SelectedTab.Name

25            Case "OptionsTabPage"

26                Try

27                    For y As Integer = 0 To chk1.Count - 1

28                        BlogList.SetItemChecked(chk1(y).ToString, True)

29                    Next

30                Catch

31                End Try

32                Try

33                    For z As Integer = 0 To chk2.Count - 1

34                        CategoryList.SetItemChecked(chk2(z).ToString, True)

35                    Next

36                Catch

37                End Try

38        End Select

39    End Sub

40#End Region

At any rate, this port is a test of the "PostToCategories" functionality. Now that I'm saving the state properly, and using the "CheckedIndices" property instead of "SelectedIndices" property, it should work. I'll know in about 8 seconds.

Are YOU In Design Mode?

interscape — Wed, 08 Oct 2003 19:51:00 GMT

Scott Hansleman talks about page instantiation while designing ASPX pages in the IDE [via Daniel Fisher]. Good stuff.

XmlTextWriter + StringWriter = Headache

interscape — Thu, 31 Jul 2003 15:17:00 GMT

I've come to the conclusion that .NET doesn't really make coding easier (yet), because most Framework classes are incomplete, and use Inheritance as an excuse to leave them that way. Case in point: XmlTextWriter.

I'm changing GenX.NET's XML formatter to use the XmlTextWriter instead of building XML manually. It's a bit cleaner this way, and I can use formatting to overcome this really weird issue I've been having with the StringBuilder.ToString method putting in breaks every 1024 characters. More on that later. Anyways, so the XmlTextWriter constructor takes an instance of the StringWriter class, which is where the problems begin. The XmlTextWriter's constructor looks like this:

Sub New(StringBuilder)
Sub New(Filename, Encoding)
Sub New(System.IO.TextWriter)

The lameness begins. So you can't set the encoding of the XML document if you pass in the StringBuilder. Sucks to be me. So I whip open the Object Browser, navigate to the XmlTextWriter, and I get the following pearl of wisdom:

Public Sub New(ByVal w As System.IO.TextWriter)
Member of: System.Xml.XmlTextWriter

Summary:
Creates an instance of the XmlTextWriter class using the specified System.IO.TextWriter .

Parameters:
w: The TextWriter to write to. It is assumed that the TextWriter is already set to the correct encoding.

Well, this would be a fabulous assumption to make, save for one thing... The TextWriter's encoding property is READ ONLY. La-de-frickin-da. Time to add bloat to my codebase again.

So I do a GoogleSearch on “XmlTextWriter StringBuilder Encoding”, and I get Roy Osherove talking about the subject. The dude knows XML & .NET, so I'm thinking “Great”.... but no dice. The examples in the comments don't work. The 2nd sample freaks out IE because the IE XSLT parser can't hack it if there are spaces at the end of the file. For some reason, converting a MemoryStream's buffer to a string kicks out extra data at the end. This is very bad. 45 minutes wasted.

The 1st example does not exactly work, because it doesn't allow for a StringBuilder to be passed in. This one is simple enough to correct, I just hate adding unnecessary code to my object model. The solution looks like this:

StringWriterWithEncoding Class:

Imports System.IO
Imports System.Text

Friend Class StringWriterWithEncoding
    Inherits StringWriter

Private m_encoding As Encoding
Public Sub New(ByVal sb As StringBuilder, ByVal encoding As Encoding)
    MyBase.New(sb)
    m_encoding = encoding
End Sub
Public Overrides ReadOnly Property Encoding() As Encoding
    Get
        Return m_encoding
    End Get
End Property
End Class

XML Parser Class:

Protected Friend Overridable Function DataReader(ByRef FromDataReader As SheetBuilder.FromDataReader) As String Implements IFormatProvider.DataReader
    Dim i As Integer
    Dim sb As New StringBuilder
    Dim writer As New XmlTextWriter(New StringWriterWithEncoding(sb, Encoding.UTF8))
    writer.Formatting = Formatting.Indented
    writer.WriteStartDocument()
    writer.WriteStartElement(“document“))
    writer.WriteElementString(dr.GetName(i), HtmlEncode(dr.GetValue(i).ToString))
    writer.WriteEndElement()
    writer.Flush()
    writer.Close()
    Return sb.ToString
End Function

There you have it. Now you can add whatever encoding you want, and the StringWriter will compensate accordingly. Notice also that the XmlTextWriter DOES NOT compensate for things like Ampersands (&) and so forth. I decided I'd take the burden off of the end user, and sacrifice a little performace by HtmlEncoding the output, rather than risk a document breaking and having to deal with a support issue.

Hopefully, MS will fix that stupid ReadOnly property and make it a two-way street, like they did with the SelectedValue property in the DropDownList. For now I'll have to use mine.

"No-Brainer Compatibility" Explained

interscape — Tue, 29 Jul 2003 07:43:00 GMT

For several weeks now, I've been talking about various issues in regards to component versioning and Framework compatibility. A few months ago, I got so frustrated by the issues that were raised, that I said I was going to start a task force to solve the problem. This task force was informal and basically consisted of Paul Alexander (XHEO) and I (Interscape Technologies). Over the past 6 months, I have really enjoyed working with Paul, and I am constantly amazed at the work he achieves. Together, we've been able to make some headway in the industry as a whole, and we have several extremely exciting things coming up in the future.

The results of this work were detailed informally in my weblog, but will be published through Builder.com officially over the next 6 weeks. By the end of the week, I will have a single, final document available on my company website. For now, thought, I want to focus on the images I posted this morning, and the role they should play with your marketing.

This overall system that I've come up with, I'm dubbing the “No-Brainer Compatibility Initiative”. This is not meant to be derrogatory by any means. It really should be a no-brainer to the people that use the reusable code that we distribute/sell regarding how it works, and which version to use it to. All too often, developers assume that the end user/other developers that will be using thair code are just as smart as they are. All too often, this is not the case. Most .NET developers are either coding newbies or coding converts. Many come from the Java realm, and just as many come from ScriptKiddieLand. Most, myself included, wouldn't know good programming methods if they came up and bit them in the ass. I'm still learning about design patterns and so forth.

So the point is to make it blatantly obvious to anyone with an IQ above 20 which version goes with which Framework. It's not that hard. The first step is to use the Framework Compatibility Graphics (FCGs) I blogged about this morning. Roy Osherove asked me, “Where do I put these graphics... in my installer or some kind of splash screen?” My answer: “Yeah those, but first and foremost, on every product-related page of your website, your documentation, and any product related support website page.” You want to build as much awareness as humanly possible. You also want to put the graphic in an and make the link to go a page with the large version of the graphic, and explain in more detail exactly what it means. Paul and I may be coming up with standard text in the very near future, to help you guys out of you're having trouble.

The next parts of this initiative stem my previous posts here, here, and here, and are addressed in greated detail in my Builder.com column next month. Paul has already taken these steps with XHEO|Licensing 2.0, as shown in the following screenshot:

Is there any question from that dialog which version you should use in VS.NET 2003? I sure hope not. As a user of XHEO's products, there sure isn't for me.

Now, this is not necessarily the best way to do it. It is, however, the best anyone has come up with so far. Try it, experiment with it, and make it better. When you do, please be sure to let me know. This is why I talk about this stuff instead of keeping it to myself.

MORE VS.NET 2003 Info

interscape — Thu, 10 Apr 2003 23:30:00 GMT

In my previous post, I talked a lot about the new Framework 1.1 and VS.NET 2003, and how they deal with the old stuff. After reading the first comments of my last post, I realized it might take more explaining than I thought. This may be a hard thing to swallow, so clear your mind, and be ready to take the red pill:

Are you ready?

=============================
VS.NET 2003 IS NOT AN UPGRADE.
=============================

Ah! Don't start talking yet. I'm not finished. Keep that mind clear ;). Now for the details.

VS.NET 2003 will not compile to 1.0. Ever. Nothing you could do will ever change it. Now, what you can do is set up a configuration file that makes the assembly attempt to run on 1.0, but it will still be compiled to 1.1.

Think of VS.NET and the Framework like conjoined twins. It's very difficult to separate the two (actually impossible). Each version of VS.NET is tied to it's corresponding version of the Framework, and they cannot be separated. VS.NET 2002 will not compile to 1.1, even if you've installed the 1.1 Framework redistributable.

If you want to still use VS.NET 2002, do not under any circumstances uninstall Framework 1.0. I cannot emphasize this enough. This will hose your system.

Who better than Early and Adopter to reinforce this notion. Read on, cutting edge developers, read on.

More VS.NET 2003/ Framework 1.1 Info

interscape — Thu, 10 Apr 2003 22:28:00 GMT

I've seen post all over the net about people nervous about installing VS.NET 2003. Having worked with it for several months now, let me allay your fears.

First off, put it out of your head that this is an upgrade. Upgrade infers replacing the current software. As with the framework itself, VS.NET 2003 is installed next to VS.NET 2002, which can also be installed next to VS7, VS6 et al. The two will cohabitate in perfect harmony (they sleep in the same bed, but VS.NET 2002 stays on top of the sheets, while 2003 like lay under the covers) with nary an argument between them.

Further, there should be no reason why the rest of you don't install the .NET Framework 1.1 immediately. It will not hose your system, and lots of people (including myself) will be distributing 1.1-compiled apps in the very near future. Just so that you know, I have it on extremely good authority that the ASP.NET Forums are compiled to 1.1.

Here's where you should be afraid. ASP.NET Component Developers: Welcome to Assembly Hell. Assembly Hell is the replacement for DLL Hell, the ol' COM buddy of ours. Assembly Hell occurs because the lack of an Application Assembly Cache when dealing with version dependancies. When dealing with an app that references 2 different third-party assemblies that in turn individually reference two different versions of the same assembly (ie a licensing component), the older version may overwrite the new version, cause a dependency error. The depths of this hell increase further because we are now going to be required to carry multiple versions of the same product for the forseeable future. Arrgh.

Something to note about .NET 1.1

interscape — Thu, 10 Apr 2003 18:53:00 GMT

Just to let you guys know, the build numbers haven't changed between the Framework 1.1 Final Beta and the Release. (v1.1.4322). I'm going to assume that this means that Paul Wilson's bug goes unfixed in the final release, but I'll let Rob Howard or Scott Guthrie answer that for me.

As for me, the final bits are on their way now. Having worked with VS.NET 2003 since the final beta came out, it will be nice to have the real deal out. I won't touch VS.NET 2002 now unless I have to. People who haven't adopted .NET yet now have no reason not to... it's not a first-generation product anymore.

The world has moved on. Come join us ;).