With all due respect to the terrible infants at digg.com who may have pinged this “a long time ago,” I notice that my WordPress.org spam comments in moderation are coming from Google, its blogspot.com site. For the last few days, I’ve been stimulated by the possibility of eliminating all comment spam from my moderation queue—but some witty person(s) out there is holding blogspot.com hostage.

The implication is that someone has the ability to set up dummy accounts at blogspot.com and use them as spam robots probably from another zombie-controlling machine. I am surprised that the kids in the hall for dig.com are not up in arms about this one… Maybe Microsoft should unleash this one the wired world to rouse some anger.[6]

Are you hip to the jive? Well let’s go daddy—go! So dig this:

string uri = "http://songhaysystem.com/xml/amazon_rest_calls.xml";

WebPermission perm = new WebPermission();

perm.AddPermission(NetworkAccess.Connect, uri);

perm.Demand();

I do not like to be right about things like this—so do not hesitate to tell me that I am wrong. It appears that the last line of code above will always throw an error for shared hosting accounts running on .NET Framework 2.0 (ASP.NET 2.0). This means that ASP.NET 2.0 REST calls are impossible for GoDaddy.com shared hosting customers.

Since I have already contacted GoDaddy.com and have an understanding about their attitude regarding this problem, this is an opportunity for competitors out there to let me—and other GoDaddy.com customers—know how you deal with this problem. Is this a Microsoft “locked trust” problem? Is this just a configuration issue under the control of GoDaddy.com?

When I am permitted to speculate, I would say that Microsoft defines a small business as one that makes just over a million U.S. dollars a year. You and I might define a small business as one that makes over $50,000 and under $100,000.

Our small businesses would definitely welcome SQL Server Express over MSDE and Access!

This probably has been obvious for many web architects but I am now guessing that the MSDNTV archive links to one page (espisode.aspx) that then loads thousands (or millions) of little XML files (manifests?) with the same schema.

This means that InfoPath users can create and edit these XML manifest files and save them to a location where the web site code finds them. This is a quick and dirty static publishing model that works perfectly for small business people who already have Microsoft office with InfoPath—dropping SharePoint into the mix can’t hurt (too much) as well.

My training is in the sciences and my discipline is in writing (for humans). This implies that I produce data on a personal level—not just on the level of a resource in some IT shop. And keep in mind that when I say the word data I refer to everything created by the Save As… command as well as DBMS storage. The WinFS world intends to make this mindset famous.

I started storing my data on the Microsoft platform because Linux was not around in my formative years—compared to the available data management technologies featuring the office analogy (windows, desktops, files and folders—and the DBMS) Microsoft was the Linux of my formative years, during the late 1980s and early 1990s.

In those days, using a UNIX system meant having academic privileges. Using a Mac meant being stuck with crappy tool like the early version of FileMaker Pro (Access 2.0 was far superior). Using an Amiga meant…

So Microsoft excelled in providing personal data management tools for “small business”—, which really means that the average citizen can perform data processing tasks that only huge organizations enjoyed. Trying to sell this concept to the general couch potato public and the “average” techie nerd seems to be very difficult. So it makes sense why the people who might fall under these gross categories would “wake up” and reject Microsoft outright.

I can’t just jump up and leave Microsoft because my data is stored in too many proprietary formats (especially my richly formatted Office documents). So for one last time, I decided to learn a new technology from Microsoft: the .NET platform featuring C#. Now that I know that this tool is available on the Linux platform (and developing on the Mac platform), I am encouraged to invest one more trek up the learning curve. I intend to get my data into standard formats (XML-based formats like DocBook and XHTML) and Microsoft will enjoy my relatively enthusiastic support of their platform and products until this process is complete. Now I do not have to “leave” Microsoft behind I just need to have the tools available to perform data interchange for all platforms I choose to recognize.

I see myself having a shallow relationship with Microsoft—right now, it’s relatively deep. The depth of this relationship is directly proportional to the shortcomings of their products. Microsoft “wants” me to have a shallow relationship with their products. They want “smart” tools that can guess what I am trying to do and “help” me do what I am trying to do without much thought and study. But at the same time, they “want” me to be dependent on the Microsoft platform.

The way Microsoft and other large commercial organizations (based on the cultural values of the Roman Empire) design dependency into their products will always find conflict with me. It is an error to assume that the Linux world will not be tempted by the desire for imperial/commercial power. It is an error to assume that I can “leave” Microsoft when I have so much data in their proprietary formats. My awareness of this fact makes me feel trapped not empowered.

I do not have to “leave” Microsoft I just need to have the tools available to perform data interchange for all platforms I choose to recognize. As of this writing, the .NET platform provides these tools.

Mike Dimmick wrote:

The new piece is, I think, the BackgroundWorker class.

Simo wrote:

Interesting question re Forms 2.0.

Does anybody know if there are improvements to the BeginInvoke / InvokeRequired/Is-my-code-back-running-on-the-UI-thread arena?

Tuesday, October 26, 2004: Understanding Chris Sells Teachings about Multi-Threading in Windows Forms: The Importance of Multi-Threading Handlers

Chapter 14 of Chris Sells, his book Windows Forms Programming in Visual Basic .NET (with Justin Gehtland on drums) explains all we need to know about implementing multi-threading designs in all but the most complex Windows Forms. Unfortunately, I had to read this chapter about five times and I had to send several stern emails to Chris Sells (which he generously answered) before I understood these basic bits:

·        Creating a worker thread can be an indirect procedure (by calling BeginInvoke) or it can be a direct procedure by getting a new Threading.Thread object. Sells discuses the disadvantages of using the latter method but I find I am able to name a new Threading.Thread object and sets is priority—I will tentatively call these “advantages.”

·        Think about implementing multi-threading handlers in the same manner you think about implementing error handling: every method that interacts with the UI thread (and is likely to be called from a worker thread) must be designed with a pattern that interrogates the Boolean InvokeRequired for true. The following is the Chris Sells multi-threading handler design pattern (written with my sense of style):

Delegate Sub MySubDelegate(ByRef WinForm As MyNameSpace.MainForm)

Sub MySub(ByRef WinForm As MyNameSpace.MainForm)



    If WinForm.InvokeRequired Then

        Dim del As MySubDelegate _

            = New MySubDelegate(AddressOf MySub)

        Call WinForm.BeginInvoke(del, New Object() {WinForm})

    Else

        With WinForm

            'TODO: Do stuff to objects on the UI Thread.

        End With

    End If



End Sub

'How will Windows Forms 2.0 eliminate the need for this pattern?

·        When InvokeRequired is always true, the flawed design is probably calling Invoke() or BeginInvoke() from an object created on the worker thread. The design pattern above avoids making this mistake by clearly showing that it is WinForm making the call (there is, believe me, the temptation to use del.BeginInvoke, which is incorrect—it puts wrinkles in Sells’ Burning Man kilt!).

·        Calling back to the UI thread from the worker thread means calling from an object that ultimately derives from System.Windows.Forms.Control that was instantiated by the UI thread.

·        The ISynchronizeInvoke interface contains the aforementioned worker-thread-to-UI-thread method invocations and the Boolean indicator that such an invocation is required. As of this writing, only one class implements this interface System.Windows.Forms.Control. Explaining why the ISynchronizeInvoke interface exists in the first damn place would have gone a long way toward why multi-threading handlers are important.

·        There is the temptation to make all Windows Forms event handlers multi-threading handlers as well. I find that this design goal creates too much code what with the writing of delegates for every single event handler. Another way is to not set form control properties directly in event handlers but to create a Client Layer of static methods that set Windows Forms controls, each with their delegates and multi-threading handlers.

·        When all of the above bits are found to be valid and not addressed by Windows Forms 2.0 kudos to the brilliant author who thunk it all up! Until then, these ideas are all my fault. Sorry, Chris.

VB6 guys would always brag about creating their first Windows Service. Now, the same VB.NET blokes would brag about creating their first Service—no, not Web Service or Windows Service, just Service. WSE provides this capability. This is attractive to me for the following reasons:

·        Code access security “complications” should not be an issue with these services. The assumption here is that the code is started by a privileged user—and the code is called by users of unknown security permissions (outside of the context of WSE security features). We may not have to be so devoted to the principle of coding for least privilege.

·        The “old” Windows Service components are bound to its hosting OS per machine while modern Service components “live” in an abstract layer punctuated with SOAP TCP addresses.

The “DTS assembly” I just built a few days ago, loaded by reflection, looks like it can loaded by WSE instead. I am certain that loading an assembly with reflection has more security complications than simply calling a Service running under higher privileges.

So, here I am actually trying to drink the Kool-Aid™ and I can’t find the cup! I am stepping away from writing it all in code and trying to inherit a control from, say an HTML Label control such that I am able to manipulate this control in the Visual Studio designer without building my own designer from the ground up.

I erroneously thought that I can just drop a Designer Attribute referring to the HTML Control Designer (or even the Intrinsic HTML Control Designer) and somehow Visual Studio would show me the appropriate Label-derived designer.

Are we forced to build our own designer for all controls we write? Is there any concept of “designer inheritance” addressed in ASP.NET 2.0? Please feel free to tell me that this question has been answered in your favorite Blog-style newsgroup so that I can find my answers there. Or it would be cool to answer a technical question here for a change.