I Already Googled It

C++ is the one area of programming that I’ve lamentably felt lacking, especially the more and more I get involved in programming specifically for Windows.  Whereas Linux/POSIX programming feels designed unequivocally for C, Windows seems to gravitate more towards C++.

So, I took the opportunity—four days off—over the Christmas holidays to learn C++ and C++/CLI.

I also took the opportunity to do something that I’ve been wanting to do for a while—make a fiber library for .NET.

I’m not going to say that it’s complete (still some stuff I want to add to it), but here goes:

Download here

Source and XML file (containing documentation) within.  If you want to compile it use cl.exe with the /clr flag on fiber_all.cpp (which #includes all the other cpp files and the header).  Remember to specify /link /DLL /out:fiber.dll if you’re just compiling the source into a DLL to use with C# or something.

Example command line invocation:

cl.exe /Ox /clr fiber_all.cpp /link /DLL /out:fiber.dll

The /Ox is thrown in to enable optimization.

As an aside: If you’re trying to compile C# code against this with csc.exe, unless you used the 64-bit cl.exe, you’re going to have to go ahead and specify /platform:x86, otherwise your C# app will throw terrible exceptions and die as soon as it starts.

How it works:

All the classes that the library uses I took the liberty of putting in the namespace System.Threading, just for intuitiveness.

.NET threads are silly in their implementation—they don’t map onto native OS threads, and may be implemented as native threads, fibers, some combination of the two, or something else entirely, which means that if you just start up a .NET application, or create a new thread in one, a call to ConvertThreadToFiber may be illegal or dangerous—all-in-all, something you don’t want to do.

The library implements a property—Fiber.IsFiber—which can let you know whenever your code is running within an existing fiber.  If you’re not in an existing fiber, and you create a new fiber, the library creates a new, native thread using CreateThread which it then converts to a fiber and immediately calls the function you provided to the fiber constructor.

Once you’re within a fiber, calling the constructor—without providing the new_thread—will create new fibers not attached to any thread, which can then be safely scheduled using SwitchTo.

The most interesting part is waiting for a group of fibers to finish. If the currently-running fiber “falls through” (i.e. ends and doesn’t call SwitchTo then the underlying thread ends. Since fibers can switch between threads, only the currently running fiber has a thread associated with it. By finding this fiber (the fiber with its Scheduled property set to true, you can get a FiberThreadWaitHandle from the WaitHandle property which will allow you to wait (just a wrapped call to WaitForSingleObject) for the underlying thread to terminate (calls to unscheduled threads will just return null).

Note that the Scheduled property is a bad way of finding the fiber to get the wait handle from, since the fiber could unschedule itself and schedule a different fiber in the time between when you call Scheduled and when you call WaitHandle, leading to a previously-scheduled fiber spitting null back at you.  You should implement your own synchronization (I like to use a ManualResetEvent at the top of my initial fiber function, which waits ’till the main thread releases it after grabbing the wait handle).

When a fiber “falls through” its Finished property will become true, which means that you shouldn’t switch to it anymore, and should call Dispose on it to make sure the unmanaged underlying data types and operating system handles get cleaned up.

Comments, concerns, questions, just e-mail me.

Link to part 1
Link to part 2

This is the third and final part of my series on how to not use Visual Studio.  Microsoft does a pretty good job abstracting the creation of boilerplate code away from you with Visual Studio, to the point that it’s fully possible to create .NET applications (both desktop and web alike) without actually knowing anything about this boilerplate code, or what it does.

As far as I’m concerned, knowing about this code, how to write it, and what it does, and being therefore able to not use Visual Studio should the need arise, enriches your understanding of the .NET Framework, and ultimately makes you a better .NET developer.

Today I’m going to talk about ASP.NET, and how to create ASP.NET pages without using Visual Studio.

The first important thing about creating ASP.NET pages that’s important to understand, is the idea of an “ASP.NET application“.  An ASP.NET application is a folder on the IIS web server that has been converted—by way of the IIS management MMC—into an application. Only within ASP.NET applications may ASP.NET pages et cetera run.  When using things like HttpServerUtility.MapPath() (referred to from within Pages etc. as “Server.MapPath()” due to the fact the HttpServerUtility of the current HttpContext is pointed to by the Server property of Pages), the root directory of the current application is referred to as “~” (i.e. tilde).

Each ASP.NET application has at least one important directory at its root: “bin“.  Within this directory, all *.dlls for the application must be placed.  You can put pages etc. in any subdirectory, any number of subdirectories deep, but anytime a page requires *.dlls these *.dlls must be in ~/bin/, where “~” is—again—the root of the application.  To elaborate, whenever a page—an *.aspx, for example—is compiled, it is linked to all the *.dlls in ~/bin/.

The above is important because you may wish to create *.dlls to use across multiple pages, and because code-behind files (i.e. *.aspx.cs) must be compiled to *.dlls and placed in ~/bin/ for their corresponding *.aspx to compile properly.

Depending on the complexity of the page that you’re creating, you’re going to be looking at one or more files.  The first file will be the *.aspx file, and the second will likely be a *.aspx.cs file (i.e. the code-behind file), and the others will likely by *.cs files that you create just to split things up nicely (this would be a good time to laugh in Java’s face because it doesn’t support partial classes (along with many other things…)).

You’ve probably gathered this from using Visual Studio, but just as a recap, the *.aspx file contains normal HTML (i.e. HTML, JavaScript, CSS, etc.) alongside ASP.NET mark-up, which is XML-style tags that begin with “asp:“—for controls—as well as tags beginning with “<%” and ending with “%>”—for directives and in-line code.

The first line of an *.aspx page should always be a directive which tells ASP.NET what kind of page it is.  Directives are contained by “<%@” and “%>“.  For *.aspxs this will—at minimum—look like this:

<%@ Page Language="C#" %>

And if you’re doing anything remotely complicated, will likely look something like this:

<%@ Page Language="C#" AutoEventWireUp="true" CodeBehind="example.aspx.cs" Inherits="examplepage" %>

Each of these attributes does something different:

• Page – Tells ASP.NET that this is a page.  Some other options here are “Handler” and “MasterPage“.
• Language – Tells ASP.NET what language this page’s code blocks will be written in.  Can be “C#” or “VB“.
• AutoEventWireUp – Allows you to handle events with specific naming conventions.  Such as a function Page_Load for when the page is loaded.  Not really necessary, but could be useful.  This is—and should be—set to “false” when working in Visual Studio, since Visual Studio automatically wires events itself (through automatically-generated designer code), and does not need the Framework wiring the events up again.
• CodeBehind – Specifies the name of the code-behind file.
• Inherits – Specifies what class the page inherits from.  More on this later.

Using what I’ve already told you, you can already create ASP.NET pages that do simple things, using in-line code using “<% [...] %>“.

This, for example, is an ASP.NET page which, when saved as a *.aspx and placed on an IIS web server in an application, will display “Hello, world!” (original, I know):

<%@ Page Language="C#" %>
<html>
    <head>
        <title>Hello, world!</title>
    </head>
    <body>
        <%    Response.Write("Hello, world!");    %>
    </body>
</html>

But this isn’t too useful. In order to write bigger, better, and more complicated pages etc., we’re going to want to separate the *.aspx and the code. We already know how to point an *.aspx at a code behind file, and specify what it inherits from, let’s discover how that all fits together.

The first thing to understand, is the idea of “Inherits“.  This is literal—the code infront page doesn’t represent an extension of the class it “Inherits“, it very literally inherits from that class. This is important because it means that methods etc. that you want exposed to the code infront page are going to have to be protected, not private (if you aren’t an accessibility level Nazi like me, and just make everything public, then you need not worry yourself over this detail).

Once you understand this, you need to understand that supplying the “Inherits” directive doesn’t make the page start inheriting from something, it makes it inherit from something other than the default.  By default pages inherit from System.Web.UI.Page, so when writing your code behind file, you need to make the class you define inherit from this.

Another thing to understand, is that if you want to access controls from the code behind file, they need to be declared—if you root around, you’ll find that Visual Studio does this in its designer code file.  Their name needs to be the same as the “id” tag in their ASP.NET markup—best practice is to declare them as protected.  If you don’t need to access them from the code behind, you don’t need to declare them (or even give them an “id” tag for that matter).

As long as a method in the code-behind is protected or public, you can access it from in-line code in the code infront file just as you would any other function (useful for cutting long in-line code blocks down—just turn them into one method call and put the rest of the code in the method in the code behind file).

Once you’re done with your code-behind file, use csc.exe to compile it to a *.dll, and put it in ~/bin/.  If you don’t do this, the Framework won’t be able to find the class your *.aspx inherits from, and will become angry.

If you want to see how it all works, I wrote a “URL Lengthener” for fun last night (it’s takes those annoying bit.ly, etc. links and tells you where they really point by following the trail of 3xx codes) using the methods I’ve outlined in these part few articles (i.e. not using VS):

• The application itself, compiled, hosted, and running.
• The source for the *.aspx (i.e. lengthener.aspx).
• The source for the code-behind (i.e. lengthener.aspx.cs).

As usual, copyleft (on the source), et cetera.

Link to part 1

So, now that you can compile your *.cs files—made without Visual Studio—into *.exes and *.dlls, what’s the next step to emancipating yourself from Visual Studio?  Most of the coding that you do in Visual Studio for—for example—a console application is writing actual code. It’s the Windows Forms Applications that really involve a VS-specific tool—i.e. the designer—so that’s what I’m going to tackle next.

All the knowledge that I have about this was gained through study of the library pages on MSDN and through study of the Visual Studio-generated *.designer.cs files that it generates as you use the designer.

One positive thing that I have found about not using the designer, and actually writing your own code to setup your Windows Forms, is the fact that you wind up with much better-designed Windows Forms on average, since you’re not just wantonly dragging-and-dropping controls (which is woefully imprecise) but are rather setting the controls to locations and sizes which are exact pixels, allowing you to easily normalize inter-control spacing et cetera.

The first thing to understand is that a Windows Form is just a class, and that when you design a new Windows Form (i.e. a custom one for your application), you’re just subclassing from this, piggybacking on its existing functionality, and tacking your own on.

Without Visual Studio there to do it for you, unless you feel like doing unnecessary typing, you’re going to need to use the namespace that Windows Forms classes are in—System.Windows.Forms. Once you’ve done this, you can create your class by declaring it and declaring that it inherits from Form.

Because you don’t have Visual Studio around to setup the form for you when it’s instantiated using code created from the designer, you’re going to need to define a constructor for this class—it’s in here that you’ll create and setup all the controls you want to put on the form, as well as other variables etc. that your application needs to run.

Lastly—as you hopefully know—C# programs don’t just startup and magically construct a class, they need an entrypoint (public static void Main () { }) which tells it what to do. You can easily create a new class to contain this method, or put it in the form’s class. I prefer the former, but it doesn’t matter. In this method, all you’re going to do is call Application.Run() on a new instance of the class of form you created.

Here’s what your completed Windows Form Application skeleton is going to look like:

using System;
using System.Windows.Forms;

public static class NewApplication {

    public static void Main () {

        Application.Run(new NewForm());

    }

}

public class NewForm : Form {

    public NewForm () {

    }

}

If you compile and run this, it should give you—when run—a blank form which persists until you close it or kill the process.

Now that we can create the skeleton of a Windows Form Application that VS abstracts away, let’s focus on putting some functionality into it.  The System.Drawing namespace is going to be important for this endeavour, because it contains two important structures—Point  (used to position controls) and Size (used to define the size of controls)—so you’re going to want to add a “using” directive for it at the top of the file.

When you create a control, there’s 4 basic things that you’re probably going to want to do:

1. Construct it (e.g. “Button button=new Button();“).
2. Size it by assigning a Size to its Size property (e.g. “button.Size=new Size(100,20);“)—bear in mind that both Size and Point use usual cartesion co-ordinate ordering—i.e. x,y.
3. Position it by assigning a Point to its Location property (e.g. “button.Location=new Point(10,10);“)—remember that these points are the position of the control’s upper-left corner.
4. Add the control to the form’s Controls property, which is a list of the controls which are on the form.  If you forget this step the control will not appear.  E.g. “Controls.Add(button);“—since you’re working within the class, you don’t need to specify its name, although you can use “this” if you’re feeling verbose.

This is just the very basic setup required to get a control up-and-running.  Different controls will have different properties you’ll want to set when you construct them, and this is what the MSDN Library is great for.

The last thing that you need to know how to do to get totally away from Visual Studio when creating Windows Forms Applications is how to handle events.  In Visual Studio you can just double-click something, and Visual Studio will create all the required code to setup the event behind-the-scenes.  Unlike Visual BASIC (atrocious language…) C# doesn’t have “Handles” syntax for events, even though “event” is a first-class citizen of the C# language.  Instead you setup your events in a more reasonable manner—by subscribing to them.

The Visual BASIC method of setting up event handlers defies a well-established paradigm in computer science—i.e. you declare where a pointer goes to, not where it comes from. The Visual BASIC “Handles” syntax obviously stands in defiance of this, and is an example of why—in my opinion—Visual BASIC is a terrible language.

Anyway, classes define events—you can find them on their MSDN Library page—and to handle them you have to subscribe to them by giving the class a delegate that you want to be invoked when the event occurs. Since C# is typesafe, and delegates are just typesafe function pointers, it matters what the signature is of a function that you pass to an event handler—you can’t just pass any old function. The signature of the delegates that can be passed to each event are documented in the MSDN Library. For example, if I wanted to handle the KeyPress event of a Form, I would need to subscribe a function that matches the signature defined by the KeyPressEventHandler delegate. To subscribe to an event, the “+=” syntax is used, and to unsubscribe the “-=” syntax is used.

Here’s a sample application that creates a Form with a Button, which when clicked, creates a MessageBox:

using System;
using System.Windows.Forms;
using System.Drawing;

public static class NewApplication {

    public static void Main () {

        Application.Run(new NewForm());

    }

}

public class NewForm : Form {

    public NewForm () {

        ClientSize=new Size(120,45);
        Text="Test Windows Form Application";

        Button button=new Button();
        button.Text="Click me!";
        button.Size=new Size(100,25);
        button.Location=new Point(10,10);
        button.Click+=Button_Click;

        Controls.Add(button);

    }

    private void Button_Click (Object sender, EventArgs e) {

        MessageBox.Show(
            "You clicked the button!",
            "Alert!",
            MessageBoxButtons.OK,
            MessageBoxIcon.None
        );

    }

}

And here it is in action:

Next time I’ll be talking about moving your ASP.NET development out of Visual Studio…

Personally, I just don’t like Visual Studio.  I’m not trying to single it out, I don’t really like any IDEs.

There are a few reasons for this:

1. I don’t like the way that Visual Studio re-arranges your code.  I write my code with very specific whitespacing etc., and Visual Studio just loves to mess with that (yes, I’ve been through the VS2010 options for formatting.  While they’re a massive improvement, they still don’t give me enough flexibility to do exactly what I want to do where I want to do it).
2. I don’t like the way Visual Studio abstracts certain things away (i.e. “designer code”, compilation, resources).  I find that in the cases where this abstraction is just doing standard, run-of-the-mill things, I can just write a batch script and do it as fast or faster.  In the cases where this abstraction is trying to do something complicated or specific, it usually messes it up and I have to go tinkering with it for a long, long time, so it’s just faster to write a batch script.
3. To me, everything needs to be configureable (or not governed by a configuration).  I always need to know what’s going on behind the scenes.  The idea of a big, monolithic IDE that I just type code into which “magically“ produces MSIL from that, is unsettling to me.
4. I think they’re terrible for learning.  When I learn new concepts in VS, it’s just a crutch so I don’t have to learn the concept completely, and then I absolutely screw it up, have to go back, and re-learn, and repeat this process until it works.  Without an IDE, there’s no crutch.  I need to learn the implementation of this new idea from the ground up, I can’t just rely on the IDE to auto-complete, auto-”designer code“, et cetera.

This is not to say that VS is all bad, merely that—in my opinion—the good out-weighs the bad.  Here are some things I wish I could have from VS without having to take the whole package deal:

1. IntelliSense (omffffffg).
2. Automatic generation of interface functions, filled in with NotImplementedExceptions (given my experiences with Mono/mod_mono, the creators of Mono/mod_mono were such big fans of this feature that they didn’t bother to go back and replace the NotImplementedExceptions with actual code).  Would make testing classes that implement interfaces a lot more straightforward, since filling in these interface functions takes time (even if copy/pasting a generic function that just throws a NotImplementedException), so I usually wind up writing the whole thing, and then testing it from the bottom up (which is time-consuming).

Regardless, this is a multi-part article which gives you the tools to not use Visual Studio should you so choose.  I thought they’d be worth sharing because—in my opinion—it’s useful to know these things, not only so you can not use Visual Studio should you so desire, but because it gives you a more intimate understanding of the way .NET in general (and especially ASP.NET) operates.

Plus, what are you going to do when you have to debug or code on a machine that either does not have Visual Studio installed (where I work we only access to a certain number of VS licenses), or (heaven forbid!) isn’t a Windows machine (blasphemy! ).

Anyway, the first tool that you’re going to need to not use Visual Studio is the ability to compile the code you generate (imagine!).  This is accomplished with the Microsoft Visual C# Compiler—also known as “csc.exe“.

The first thing to do—unless you love typing long paths—is to add the path to csc.exe to the Windows path.

On Windows Vista/7:

1. Hit WINDOWS KEY+PAUSE.
2. Go to “Advanced system settings“.
3. Click “Environment Variables…“.
4. Under “System variables” locate “Path“.  Click it and click “Edit…“.
5. To the end of the current “Variable value“, add a semi-colon—which delimits entries—and add the path to the version of csc.exe that you wish to use. If you’re using .NET v3.5, this path will be—assuming you have Windows installed in the usual location—C:\Windows\Microsoft.NET\Framework\v3.5.
6. Hit “OK” until the dialogs are gone, and then clock the system properties window.

On Windows XP (why are you still using this?):

1. Hit WINDOWS KEY+PAUSE.
2. Click the “Advanced” tab.
3. Continue from step #3 of the Vista/7 instructions.

Now that csc.exe has been added to the Windows PATH, you can invoke it from the terminal merely by typing “csc“, which simplifies matters greatly.

csc.exe‘s, useage is as follows:

csc.exe [flags] [source files]

“[S]ource files” consists of a space-delimited list of the source files you wish to compile (you can specify as many as you want).

“[F]lags” consists of any of the csc.exe flags.  Here are some of the more useful/common ones:

• /out:<destination> – Specifies where the compiled file will be placed, and what it should be called.
• /o – Tells the compiler to optimize.
• /reference:<file> – Tells the compiler that the specified source files should be built with a reference to the specified library (usually a *.dll).
• /target:<type> – Tells the compiler what kind of output you want.  Options: “library” (for a *.dll), “exe” (console executable), “winexe” (Windows executable), and “module” (a module that can be added to another assembly).
• /doc:<file> – Tells the compiler to parse XML comments and write the resulting XML to the specified file.

Since projects—particularly larger ones—typically involve many *.dlls, it can be beneficial to—as I mentioned above—put your invocations of csc.exe in a batch (*.bat) file, and run the batch file whenever you want to rebuild.  That way you’re absolutely sure that you’re working with a properly-built, up-to-date version of all resources each time you test.

The next thing to touch on is that—since VS isn’t around to take care of it for you—C# code doesn’t actually specify resources that it must use.  For example, if you write some C# and you’re planning on using useful.dll later on, you don’t need to put anything in the C# code that talks about referencing that DLL—you do that through the compiler with the “reference” flag.  What you do need to do is add “using” directives to the top of your source files unless you want to type out the full namespace of every class etc. everytime you use it.  For all projects, your code should probably start off with “using System;“—since most things you use (the String class, for example) are located in this namespace—and this single directive should expand to more and more as you find the need to use classes from additional namespaces.

Bear in mind always that these “using” directives don’t actually import anything.  You’re—as I stated above—not adding references etc. when you put them in your source code, and at the end of the day they don’t even change the code that the compiler generates.  They just allow you—by typing “using System.Collections.Generic;“—to type “List<String> alist=new List<String>();” rather than “System.Collections.Generic.List<String> alist=new System.Collections.Generic.List<String>();“. Given “using System.Collections.Generic;“, both of these have exactly the same meaning to the compiler—”using” is there for your convenience and for that purpose alone.

Well, that’s all for today.  In the next part I’ll talk about building Windows Forms Applications without Visual Studio and it’s handy designer.

So I’m happy that I can now see who’s linking to my blog—whether they use PingBacks et cetera or not—which got me thinking that it’d be somewhat cool to do the same thing for my homepage, which is written in ASP.NET.

So here’s code that does exactly the same thing as the PHP code I posted in my last blog post, except with ASP.NET (and C#):

try {

    if (Request.UrlReferrer!=null) {

        Response.Write(
            "<div class=\"categorybox\">You were linked to here from <a href=\""+
            Request.UrlReferrer.ToString()+
            "\">here</a>.</div>"
        );

        Boolean exists=false;
        using (System.IO.StreamReader read=new System.IO.StreamReader(
            new System.IO.FileStream(
                System.IO.Path.Combine(
                    Server.MapPath(null),
                    "referrerlist.txt"
                ),
                System.IO.FileMode.OpenOrCreate,
                System.IO.FileAccess.Read,
                System.IO.FileShare.Read
            )
        )) {

            String holdthis;
            while ((holdthis=read.ReadLine())!=null) {

                if (Request.UrlReferrer.Host==holdthis) {

                    exists=true;
                    break;

                }

            }

        }

        if (!exists) {

            using (System.IO.StreamWriter write=new System.IO.StreamWriter(
                new System.IO.FileStream(
                    System.IO.Path.Combine(
                        Server.MapPath(null),
                        "referrerlist.txt"
                    ),
                    System.IO.FileMode.Append,
                    System.IO.FileAccess.Write,
                    System.IO.FileShare.None
                )
            )) {

                write.WriteLine(Request.UrlReferrer.Host);

            }

            System.Net.Mail.SmtpClient mail=new System.Net.Mail.SmtpClient("192.168.50.4",25);
            mail.Send(
                "noreply@rleahy.ca",
                "rleahy@rleahy.ca",
                "Your Website Has Been Linked To",
                "The domain "+
                    Request.UrlReferrer.Host+
                    " has started linking to your site from "+
                    Request.UrlReferrer.ToString()+
                    "."
            );

        }

    }

} catch { }

Since .NET’s SmtpClient doesn’t pull from a configuration file–unlike PHP’s mail, which pulls SMTP settings from php.ini—there are few more “fill in the blanks” as opposed to yesterday:

• Your SMTP server’s IP/hostname.
• Your SMTP server’s port.
• The from address for your server.
• The to address (just like the PHP script).

If you want to be a real keener—or if it just fits in with your application—you can replace these “blanks” with calls to ConfigurationManager.AppSettings and store all of that in your web.config file.

Other than that, just put it between <% and %> anywhere in your *.aspx file, and you’re set.

If your environment uses authentication or SSL for SMTP, read the SmtpClient documentation and adjust the mailer portion accordingly.

Afterthought: This is the first blog post I’ve made before midnight…what a night owl I am…