OCDProgrammer.com

Last week I came into the office to find my box was completely hosed.  I kept getting a compile error that the webengine.dll could not be found. 

I tried many different uninstalls and reinstalls of .NET but it wouldn’t fix the problem.  However I notice that even though .NET was uninstalled, it wasn’t.  I went looking for a tool to completely uninstall .NET and found this website.

After using that process to uninstall .NET and then rebooting, I reinstalled .NET and was good to go.

Was one of the most frustrating work days I have had in some time, have never been so close to being beaten by a technical problem like this.

I’ve been doing some work on the DotNetBlogEngine and recently I would get this error when I tried to debug.

Thankfully after an online search I found this solution.

In short, open up your .SLN file in notepad and edit the VWDPort entry to a lower number.  You should be up and running after that. 

Thanks to JBERKE for the help!

In the past, Chris Blankenship had written a user control to show the recent referrers in DotNetBlogEngine.  I’ve used it on my site since then.  However in a recent upgrade of the code base it stopped working.  Having a little free time on my hand, I took the time to fix it for version 1.6. 

While doing that I wanted the ability to white list and black list certain domains.  The logic in DotNetBlogEngine to see if a referrer is spam is a little limited.  It does a simple web request on the referrer to see if it can find the host domain in the returned HTML.  This leads to a lot of good referrals being marked as spam.  Then there are some ‘good’ domains that I want hidden.

So I added a white and black list to the referrer page.

The end result you see on the side bar of my site. 

If you’d like the code, you download it below.  This change does require a recompile of the business logic dll, and a schema change if you are using SQL.

Download Referrer Patch 1.1 – 31.4KB

Comment spam on the DotNetBlogEngine platform has been a huge frustration.  Spammers have taken aim and generally have won. There have been various solutions offered up from the community.  Version 1.6 was almost solely targeted to combat spam.  So what happened?  The spam got much worse.

So in this cat and mouse game a new trick has been deployed.  Filip Stanek has incorporated the reCaptcha solution into DotNetBlogEngine. 

I deployed it last night and went from 20+ spam comments a day, to none so far.  Now, obviously, this is just another step on the cat and mouse game.  Will be interesting to see how long this works.

As covered in my prior post, I recently went on an in depth search for a web host.  I ended up at JODOHost.com.

Their price was unbelievable.  For unlimited sites, 4.5 GB of space, 65GB of transfer, and much more it is only $17.50 a month.  The great thing about this is that you can have Window servers and Linux servers. 

They actually support multiple domains in a true way, all the other host had their domains as sub directories of a root domain.  That isn’t the case with JodoHost, a domain is a unique folder.

They are based out of India, and there is an honest and fair criticism from Indian tech support about it being poor.  However, overall, I have found Jodo’s support to be more than acceptable.  There has been the occasional person who was below par, but I get that with American based support companies as well.

The only thing I don’t like is that you can’t make a folder writable on your own.  You have to open a support ticket so they can change that for you.

Overall, if you are looking for an ASP.NET host, JodoHost was by far the best one I tried. 

I’ve been on the search for a web host.  I’ve used Jetsoftdev/Devserve hosting for many years.  It was a bit of a trade off, I’d help manage their server and get some free hosting as well.  That worked great, but I honestly just got tired of having to manage the server so much.  I went on the look out for a new webhost that was reasonably priced but loaded with features. 

Specifically I needed multiple domain support.  I want the ability to host several sites for the base price.  Then, it had to be Windows based.

The journey was an interesting one, to give the short answer.  JodoHost.com won.  Godaddy, 1and1.com, and aplus.net lost.  I’ll go over the reasons why below.

For all providers, lets assume the fact that we have three domains and one of those has to be your ‘primary’ domain.

Root: example.com
2nd Domain: example2.com
3rd Domain: example3.com

I started with APlus.net.

This exposed me to the first problem that many host share when it comes to hosting multiple .NET domains.  I can’t speak for non-.NET sites as I don’t currently maintain any of those.  But .NET is configured to operate within “Applications” and the problem shows up when the host is using some fancy URL Rewriting to make ‘multiple domains’ possible.  When a .NET site has to search for its root directory, it will show it as it is setup in IIS. 

The problem here is when your file structure looks like this:

web\example.com\

web\example.com\example2.com\

web\example.com\example3.com\

So the following URL’s would (or should) be valid:

http://example.com/
http://example.com/example2.com/
http://example.com/example3.com/
http://example2.com/
http://example3.com/

The problem arises though, in that http://example2.com will show up as: http://example2.com/example2.com/ 

In trying to get this issue resolved along with some email issues, I found Aplus.net’s support to really be lacking.   Slow, to no reply.

Next I tried 1and1.com. 

I found the exact problem as aplus.net with the multiple domains. 

So I moved on pretty quickly as I had learned my lesson

They were, however, a bit slow to refund the initial fee that I paid to setup the service.

Next on the list was GoDaddy.com.

During my initial tryouts of GoDaddy.com I thought I had finally found my solution.  Unfortunately, however, they turned out to have the same .NET problem with multiple sites. 

I was a bit bummed. 

Their support was two fold.  It was always available, but at times kind of slow to react.  Many times they told me to wait 24 hours for changes to take affect (server changes, not DNS changes).  Then those changes would never take affect and they would have to reschedule the batch function to run and fix the issue, which could take another 24 hours.   This is why it took me so long to realize they had the same .NET issue.

Finally I did some more searching, and found JodoHost.com

I took a look at some of their plans, and found that their Reseller Hosting plan was perfect for me.  It was unlimited domains, 65 GB of traffic, etc.. Makes no sense to use their basic web hosting plans when their reseller hosting plans give you so much more.  If you are looking for just a basic web host, then there are cheaper options out there.  This, for me, was the best option I could find.

I’ll write a specific follow up post for JodoHost.com soon.  I want to make sure the good and the bad is not lost in such a long post.

I am always looking for a way to justify dropping support for IE 6 as a web developer.  Generally, for small projects, I won’t officially support a browser less than 10% of market share unless the client requires otherwise.  I never waist my time on browsers that are less than 5%.  I just have better things to spend my time on, and I don’t feel bad that Safari decides to render differently than the other major browsers. 

I code to standards and don’t want to go down the rabbit hole of supporting EVERY browser’s unique issues.

Yesterday Michael Wood mentioned that IE 6 was really starting to trail in use.  So I went looking at my stats and was stunned to see how far it had fallen. 

So can you help?  If you would send me your website and browser usage I would appreciate it.  You can comment below, or email me.  If you want your site to remain anonymous, just let me know.

I am looking for the following information:

Top 3 to 5 browser brands (IE, Firefox, Safari, etc..).  Then top browsers by version:

IE 8, IE 7, FireFox, IE 6, etc…  With the percentages.

Thanks!

One thing I learned over the past few months had to do with sharing a website from one site to another via an iFrame.  The problem arises when the domains don’t match.  If your primary site is example.com and the site in the iFrame is exampleinaniframe.com, by default exampleinaniframe.com cannot set cookies or execute certain JavaScript.  Browsers see this as a potential hijacking and throw a security error.

The fix for this is pretty simple, but not simple all at the same time.  There is a header you can add to  your site telling browsers that it should allow it to be put in an iFrame.  Those are called P3P Header’s.  Now the hard part to this is that a search online returns a lot of conflicting answers to what your header should look like.  Then one night, as I was trying to figure out how to do Facebook development, it hit me.  That is how Facebook works.  All of those applications you use in Facebook are really hosted on another site, you just see it seamlessly via an iFrame.  Now since Facebook has 350,000,000 users I figured they probably have this figured out.

A brief search found this very simple and concise P3P header, all you have to do is include this somewhere early in your page load life cycle (global.asax, httpmodule, basepage, etc…):

HttpContext.Current.Response.AddHeader("p3p", "CP=\"CAO PSA OUR\"");

That will tell the user’s browser to not throw a security exception and allow the site to function as needed.

I have been an ASP.NET developer since I joined the team at Cintech in 2006.  I’ve been in the web form world and all the wonders of the PostBack page model since then. 

Then around the end of 2008 I remember hearing some noise about an ASP.NET MVC project released by Microsoft that got some bad reaction.  Talking about how it wasn’t a good start to MVC.  I never took the time to look deeper as I had other things going on in life, and was happy with my PostBack world.  Turns out this was a project called “Oxite” that is hosted over on CodePlex.

Then July of this year I took a job with a long time friend at Epsilon.  My friend is a Java developer, and through our conversations he kept telling me about this “MVC" way of doing web development.  About how it is so different than how he was being forced to develop on the .NET project we were working on together. 

The more he talked the more I got interested in learning about this new ASP.NET MVC that Microsoft had released.  Around this time CINNUG hosted a firestarter event going over ASP.NET MVC.  I took a Saturday to attend the event and learn some more.

In general I’m eager to learn more and put some of this in action.  This is when I went looking for that project that Microsoft put out.  Upon finding Oxite I see that it was basically a dead project.  The only thing I could find was a post on Erik Porters blog stating this in the comments:

October 08, 2009
Jeff, there is news coming about Oxite, but unfortunately I can't share anything until some other news happens. :( It's looking right now like that news is still a month and a half out. Really sorry! :(

Now this is on top of the fact that Oxite had not moved much since July.  Check ins, yes.  But nothing worth writing home about.  Then in the comments there was some guessing that Oxite was going to become “Orchard”, which was discussed as being a full featured CMS backed by Microsoft, though still being open source. 

Now I had high hopes for Orchard.  Since Oxite had been dead for months, I figured this new Orchard product would be ready to go when released.  I was stoked and waiting for it to be released.  I was all set to move this site to use the Orchard codebase.  When it got officially released I downloaded it, compiled it.. then ran it locally.  Wow, was I ever disappointed.  Orchard is months away from being usable, so here we are in the community with nothing to use.  From what my brief research shows me, at least a year after the release of ASP.NET MVC we have made very little progress in expanding this for people to actually use. 

As harsh as this may sound, I blame Microsoft and I blame the Oxite team. A person named Adam created a discussion on CodePlex stating the following:

October 12, 2009
Guys,

At the moment, I feel that Oxite is hindering developers from creating new ASP.NET MVC blog engines because Oxite is already there, on the other hand, the current official release of Oxite is missing load of features and cannot be compared to other popular engines.

If you are not planning to release soon or you are very busy, just declare this project as no longer supported to open the chance for other developers to start their own engines...

Regards,

Adam

I totally agree.  People don't want to waste their time recreating the wheel when there is a project already out there.  But here we are, over a year has passed and we have very little ‘real’ stuff to show.

Microsoft needs to get its act together.  Many great developers are abandoning the .NET platform for platforms like Ruby, and if you lose developers you lose the market.  Customers don’t care what platform people use, they just want their problems solved.  If those problems are solved and the developer chooses a non-Microsoft technology, then Microsoft loses.

Maybe Orchard is the answer.  Maybe six months from now this blog post looks like the most foolish blog post on the web.  For now, however, I’m still looking for the next big thing.  What comes after .NET for me professionally?  .NET won’t be around forever and being a fairly young man, I have to look toward the future to keep myself professionally relevant. 

In a .NET world ViewState can get out of hand in a hurry.  In some of our more intense pages the ViewState created by controls could reach well into the 50% range of the page size.  A brief search by a coworker found this solution.

The main thing to take from this article is to insert this snippet of code in your page, or custom base page:

    protected override PageStatePersister PageStatePersister
    {
        get
        {
            return new SessionPageStatePersister(this);
        }
    }

This little beauty of code can reduce the ViewState by 90+%, which is significant.

Now the obvious limitation to this is that your real ViewState is now stored in session, so this will add some overhead to your web application.