Brendan Tompkins : ASP.NET

Using Embedded Resources for HTML Email Templates

Brendan Tompkins — Wed, 24 Oct 2007 15:23:00 GMT

Most web applications need to send out email for a variety of purposes, right? I like to use email as a sort of extended user interface - allowing entry points to let the user conveniently do work by getting an email and clicking on a link. I've struggled for a while with a good way of managing email templates to use in my applications. I recently found a good project that simplifies the process of templating - See Alexander Kleshchevnikov's excellent solution for managing and sending emails inside a web application.

I like his template approach, but I don't like to keep my template files in a directory with my web project, mainly because it tightly couples these files and a certain directory structure to the classes that actually do the email work. This makes my classes harder to test, re-use and deploy. I recently figured out how to embed these templates into my class' assembly files, making the class much more useful.

To embed a resource, just drop it in your project, and select "Embedded Resource"

Using Alexander's solution for templating, and an embedded resource html file for a template, the code to use this resource looks like this:

        public static void SendRegisterNotification(User user)
        {
            Hashtable templateVars = new Hashtable();
            templateVars.Add("FirstName", user.FirstName);
            templateVars.Add("LastName", user.LastName);
            templateVars.Add("Login", user.UserId);
            templateVars.Add("Password", user.Password);

            Parser parser = new Parser(templateVars);
            Assembly asm = Assembly.GetExecutingAssembly();
            Stream stream = asm.GetManifestResourceStream(asm.GetName().Name +
                ".Registration.htm");

            using (StreamReader reader = new StreamReader(stream))
            {
                parser.TemplateBlock  = reader.ReadToEnd();
            }

            // Send email
            System.Net.Mail.MailMessage message = 
                  new System.Net.Mail.MailMessage();
            message.To.Add(user.Email);
            message.From = new MailAddress("brendan.tompkins@gmail.com");
            message.Subject = "Your StreetTurns.Com Account Information";
            message.Body = parser.Parse();
            message.IsBodyHtml = true;
            SmtpClient sc = new SmtpClient("StreetTurns.Com");
            sc.Send(message);
        }

Yes, but what about Modifying your Templates?

As Jeremy Miller has pointed out, you shouldn't be afraid to compile and release your code. If you are, you need some serious work on your build process. To me, the benefit of having one class that I can drop anywhere without worrying about permissions, file paths, and all that far outweighs the need to re-build the DLL when I make a text change.

I'm pretty happy about the way this all works. For more on embedded resources, ther's some information here and here about how you can access your resources via a URL in a web app.

Formatting Code with dp.SyntaxHighlighter

Brendan Tompkins — Wed, 08 Nov 2006 21:15:00 GMT

I've run across a cool syntax highlighter for use on web sites called dp.SyntaxHighlighter. It highlights (and more) the following languages:

Not only that, but it does a fantastic job of rendering too.. check out this little snippet of C# code.

/// <summary> /// Gets a polygon from a string /// </summary> /// <param name="strPoly">(0,253),(370,115),(417,122),(456,92),(563,101),(303,477),(0,479)</param> /// <returns></returns> public PointF[] GetPolygon(string strPoly) { strPoly = strPoly.TrimStart(new char [] {'('}); strPoly = strPoly.TrimEnd(new char [] {')'}); strPoly = strPoly.Replace("),(", ":"); string [] strPointCoords = strPoly.Split(new char[] {':'}); PointF[] points = (strPointCoords.Length > 0) ? new PointF[strPointCoords.Length] : null; for(int i = 0; i< strPointCoords.Length; i++) { string [] pair = strPointCoords[i].Split(new char [] {','}); points[i] = new PointF(Convert.ToInt16(pair[0]), Convert.ToInt16(pair[1])); } return points; }

You have to install some javascript(s) and styles along with your blog engine, but once that's done, all you have to do to get the output you see here is wrap your code in some <textarea> tags.

-Brendan

Building a Better Jobs Site...

Brendan Tompkins — Tue, 10 Oct 2006 13:53:00 GMT

I'm thrilled to announce Jobs.CodeBetter.Com; a new job board and job ad syndication service created by Eric Wise and myself over at CodeBetter. "Oh no, not another job site!" you're thinking. Yes, we were influenced by other new jobs posting sites, but we think we can do better for a variety of reasons.

We're focused - We're syndicating to only highly focused blog sites, like here, codebetter.com, hanselman.com, winsmarts.com - this allows companies who post jobs access to the "cream of the crop" of developers. If you're reading these sites, you're no mort. :)

We've setup a revenue model for affiliates that works. We give our affiliates a premium for each job posted via a link from their sites, even if they bookmark us and come back to post a job later. In fact, we'll pay our affiliates for every job posted by that person into the future. It can be a great way for bloggers to monetize content. This is what makes it all work. Eric says it best on his announcement post:

...we acknowledge that we owe the blogosphere in general a lot for the success of Codebetter.com. As such, we want to ensure that all of our friends and contacts in the blogosphere can make money right along with us. Thus we have launched an affiliate program, if you have a technical blog/site, all you have to do is register as an affiliate and then put some javascript on your site. This javascript randomly displays active jobs from our feed ala Google Adwords. You will be create a referral code during to put into the script, and if employers find us and post jobs because of you, you will receive $105 for every ad they post, for life. In this way, not only do we help fund our brothers and sisters in the blogosphere, but we also add value to employers as unlike other job sites where your job exists only in one place, when you post with us your job can be shown on potentially dozens of other sites.

It's good blog fodder too

Eric and I jammed on this project. I'm not one to toot my own horn, but we did this in a very short timeframe... We used some really good IMO tools... SourceGear's Vault allowed us to work remotely together easily. We used many of the new ASP.NET 2.0 and SQL 2005 features... there's a lot of cool stuff in there that we hope to blog about in the future. One post I'm going to do very soon is an explanation on how we created our JavaScript syndication ads. Ever wonder how sites like Google and Blogads create the ads you see on affiliate sites? I'm going to show you how we did it... so stay tuned.

So, thanks for reading this, and please help us out by spreading the word!

Brendan

Speed Up VS 2005 Web Development - Kick your App_Code Habit

Brendan Tompkins — Fri, 22 Sep 2006 20:28:00 GMT

Scott Guthrie talks about how to speed up build times for Visual Studio 2005.. It's a great read, and definitely something to know inside and out if you're doing ASP.NET development with VS 2005. You've got to hand it to a person in his position doing down and dirty blog posts to help us little guys out, from what I hear and from recent personal experience, he's very accessible.

In his post about build performance, he actually has a good nugget of wisdom about overall performance of the IDE as well. He mentions this:

Keep the number of files in your /app_code directory small. If you end up having a lot of class files within this directory, I'd recommend you instead add a separate class library project to your VS solution and move these classes within that instead since class library projects compile faster than compiling classes using the /app_code directory.

This will speed build time, but will also speed up your design time experience as well. Why you ask?

I recently spent some time on the phone with Bradley Bartz from MS, who explained this very slowly and patiently to me. I hope he'll let me know if this isn't right, but from my understanding, Every time you make a change to a file in the App_Code directory, this invalidates the Visual Studio's internal cache of classes in this folder. The very next time you try to open a designer for an ASPX page or ASCX control, VS has to re-compile this folder to get the metadata it needs for the design-time rendering of the control. This can cause the IDE to slow to a crawl. One the classes are cached, things speed up significantly in the IDE.

This was a big eye opener for me. I'd been using the App_Code folder as an easy way to get a globally accessible class in my web projects. If it was stuff that only was related to the current web site, I felt this was a good choice for where to put the code. The problem was, I was banging up against this slowness all the time. I'd get some class designed, tab over to a page or control to do some databinding and find myself waiting in frustration, my development rhythm shot. Little did I know that I was waiting on a compilation of the entire App_Code folder.

So, I'm going to seriously wean myself off of this folder, in favor of a separate dll project for these situations where I need a class to be visible across controls or pages.

-Brendan

Why are ASP.NET Developers Jumping Ship?

Brendan Tompkins — Fri, 15 Sep 2006 13:25:00 GMT

James Avery talks about Pete Wright leaving Microsoft

I have a ton of respect for Pete and look forward to reading about his new experiences. I know more and more .NET developers who are playing around with RoR in their spare time, I wonder how many will convert over the next couple years?

I too wonder how many ASP.NET developers will jump ship to RoR. My interest has definitely been peaked, ever since I first saw that great Rails demo.

Other than wondering how many will defect, I also wonder why ASP.NET developers are jumping ship.. Could it be that...

VS.NET is no fun to use

Our IDE is currently in a fairly broken state (if you use VS 2005 for web development, you know what I'm talking about). I've taken to watching lots of Google Videos while I wait for builds, gets, controls to load, etc. It's impossible to get a good web development rhythm going with the IDE currently. Frankly, I think that this has been a major factor. It's not something that's easy to put your finger on, but after months and months of mild frustration with development, playing with RoR is a lot more fun than playing with a new future MS technology. Perhaps SP1 will fix this?

Everything else currently released by MS is less than thrilling

I'm talking about ASP.NET 2.0 and C# 2.0 here. With ASP.NET we've been handed a new project model with debatable benefit. At least for me and my team, it's caused more problems than it's solved. Also, there's not much new to implement in our day to day coding. Yes, we've been given some new controls, but these mostly solve problems that if you've been doing ASP.NET development for a while, you've already solved (membership, master pages, etc). So at best, a seasoned ASP.NET Developer is faced with the task of ripping out working code and replacing it. Whoohooo. Fun.

The only thing I can say that's been given to me by MS in the last two years that I really use, saves coding time, and gives me warm fuzzies about MS are C# generics.

I know there's good stuff coming

Now, I know there's good stuff on the horizon. ATLAS, WPF, WCF to name a few. Some very smart people over at CodeBetter seem to be very excited about these new things. I for one can wait. But this current state of things is giving me enough time to poke around with things like RoR. If RoR can be compelling and fun enough, it's going to grab some converts. MS better hurry up and throw us some bones.

-Brendan