** EDIT **

I since had this problem start reoccuring even after the changes I specified below.  I finally came across a knowledgebase article on Microsoft's site that deals directly with this issue.  I took the advice from that article and applied the required changes to BOTH the server and my workstation environment.  It seems to have cleared up the problem and the speed of which I am able to compile over the network has also increased

If anything further changes, I'll edit this post again. Keep on reading for background information.

Here's the link to the Microsoft Knowledgebase article: http://support.microsoft.com/kb/810886.

--- Original Post ---

*Phew* What a long title for a blog entry.  My apologies, but I know it will help to push this entry up in the search engines so that more folks can find this simple solution.

So, to start off I'll give a bit of background information on the platform I'm running:

I experienced this error in Visual Studio 2010 while working on several ASP.NET sites hosted on my virtual Windows Server 2003 system.  I have my projects setup in such a way that I share my virtual server's \inetpub\ folder on my local network so that I can directly load the web sites I develop straight from the server into Visual Studio 2010 (I actually have the folder mounted as my W:\ drive in Windows 7, but that's beside the point).

In Googling / Binging for an answer I came across multiple posts stating that I should simply "not" host the web project on a UNC path and instead bring a local copy over to my development machine to work on.  Since I've never had to do that in the past and since I find my setup works perfectly fine for me I didn't settle for that answer.  I did, however, come across one poster who stated that he reset the Application Pool for the offending site and everything was back to normal.

So, I did just that!  I logged into my virtual Windows Server 2003 environment, loaded up IIS Manager, stopped the web site hosting the solution, stopped the Application Pool hosting the web site and then retarted both in the opposite order (started Application Pool, started web server).  Voila!  All is well again.  It really is THAT simple. 

I hope this helps others fighting with this silly error!  I had been experiencing it off and on for a couple of weeks and then suddenly it started happening every time I attempted to build any web project in Visual Studio 2010.  I'm glad to see the error had nothing to do with Visual Studio and everything to do with the IIS environment.

Now, I realize that in a production environment this may not seem like the best solution (although it doesn't require a full reboot of the server).  However, if you were experiencing this problem on a production server then you should really be asking yourself the question "Why on Earth am I accessing production copies of my web site source files from Visual Studio?".  I've recently moved over to using SVN for most projects and designating production server file locations as check-out locations.  This makes updating the production servers much easier... but that's a whole different blog post. 

Well, I'll start by saying this: I learned this the hard way.

In other words, I spent the better part of my day, yesterday, attempting to get a SECOND table of data using the SqlCacheDependency to cache properly.

Here is what I learned about the query "rules" that don't happen to be documented well (or at all?):

DO NOT USE 'text' or 'ntext' column types in your query (possibly not in the table, either)!!!

The SQL server was dropping various errors in its log about the service broker failing to get the data (and on the front-end of the web app the data would not cache, but kept requiring a reload).  It turns out this simple query was failing due to the use of an [ntext] column field:

SELECT id, Code, Name, Value FROM LanguageEntries

The [Value] column was of type 'nText'.  I changed the column to an 'nvarchar[MAX]' type and all is well.  The service broker properly gets the data and my code properly stores it in the web cache as expected.  After debugging the server for hours (including installing service packs, setting a master key on the database (the log told me to! lol), etc) I finally gave up and created a brand new, super-simple table and noticed that it cached properly.  At that point I decided to slowly change that table to resemble my original "LanguageEntries" table and low and behold I found the problem!

So, word of the wise: if you're pulling your hair out trying to figure out why your service broker is failing to update the web app's cached data, it may be due to a simple column-type conflict. ;)

I thought I would post this here in hopes that it helps out others that come across this problem in the future.

I use GoDaddy as a host, and since I get 25 MySql databases with my hosting package and only 2 MSSQL databases, I wanted to find a way to properly utilize those MySql databases with ASP.NET.  In the past, I have avoided the use of databound controls such as GridView when using MySql databases because, to be brutally honest, it just never worked very well.  By "very well" I mean it was a lot of extra work to make it happen, and when you're pressed for time, that's never work you want to actually be doing.

Last evening I did some Googling and came across some information that allowed me to hookup databound controls, such as GridView, using a MySql database and keeping ALL of the features of those databound controls (such as paging data, sorting, etc).  This is great news!

First things first, you want to get yourself a copy of the latest MySql Data Connector (Connector .NET) on the mysql.com site.  I grabbed 6.0.4.0 last night from here:

http://dev.mysql.com/downloads/connector/net/6.0.html

Once you've installed the connector (or extracted it), find the MySql.Data.dll file and drop it in the \Bin folder of your ASP.NET web project.

Next, you need to edit your web.config file and add the following information.

Place this just after the closing of your "Connection Strings" section:

     <system.data>
      <DbProviderFactories>
        <add name="MySQL DataProvider"
             invariant="MySql.Data.MySqlClient"
             description=".NET Framework Data Provider for MySql"
             type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.0.4.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D" />
      </DbProviderFactories>
    </system.data>

Place this inside your "Assemblies" section.

    <add assembly="MySql.Data" /> 

That should do it for your local development efforts (there is more below for GoDaddy specific setups).  You can now use <asp:SqlDataSource> with your MySql database, but just be sure to provide your "ProviderName" to the control as well or else it will attempt to use the MSSQL provider type.  ex:

    <asp:SqlDataSource ID="SqlDataSource1" runat="server"
        ConnectionString="<%$ ConnectionStrings:ConnectionString %>"
        ProviderName="<%$ ConnectionStrings:ConnectionString.providerName%>">
        // etc..

    </asp:SqlDataSource>

No, on to GoDaddy specific web.config modifcations.

GoDaddy requires a simple change to the web.config file in order to support the MySql Data Connector:

  <system.data>
    <DbProviderFactories>
      <remove invariant="MySql.Data.MySqlClient" />
      <add name="MySql Data Provider"
           invariant="MySql.Data.MySqlClient"
           description=".NET Framework Data Provider for MySql"
           type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.0.4.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D" />
    </DbProviderFactories>
  </system.data>

(NOTE the <remove /> addition)

And that's it!  You can now use your local (or GoDaddy) MySql databases with ASP.NET and enjoy the databinding features you're used to with MSSQL databases. :)

One final comment, here are some connection string examples for those searching for how to setup their MySql connection strings in web.config:

GoDaddy (the database login is always the same name as the database itself):

<add name="ConnectionString" connectionString="Data Source=MyDbLogin.db.4112315.hostedresource.com;User Id=MyDbLogin;Password=MyDbPassword;connect timeout=10;Database=MyDbLogin;Pooling=false;" providerName="MySql.Data.MySqlClient" />

Local Development on a virtual server:

      <add name="ConnectionStringDev" connectionString="Data Source=localhost;User Id=MyDbLogin;Password=MyDbPassword;connect timeout=10;Database=MyDatabase;Pooling=false;" providerName="MySql.Data.MySqlClient" />

Done!

I hope someone benefits from all of this!  I spent about 3 hours last night getting this all to work properly, so I hope it can save someone else some time now that it's documented.

I recently started using the Beta version of Visual Studio 2010.  I have to say that I do like it quite a lot.  Granted, it does have a few bugs (try selecting text in a line that is beyond your view pane's visible region.. the cursor doesn't properly move the view pane along with your selection).

The biggest improvement, in my eyes at least, is the IntelliSense.  It's almost on par with Whole Tomato's latest efforts with their Visual Assist X product.

Anyone else want to share their thoughts?  I personally haven't dove into any of the .NET 4.0 features just yet.  Until it becomes a defacto standard on web hosts, I probably won't get too involved with that just yet.

I think this image speaks for itself. ;)

 

Yes, that's the latest version of Eclipse IDE, working on a Java Server Pages (.jsp) page with some CSS scripting.  Nothing compares to the quality of Visual Studio!

I just had to post about this.  SCO's CEO posted his regular partner news update and all he had to say was "Blah. Blah. Blah.".

Check out the original posting here (if it's still there!):
http://www.sco.com/partners/news/0901/200901.html

Here's a news story I found on this just after coming across the original:
http://www.channelregister.co.uk/2009/02/05/sco_blah_blah_blah/

You have to love how a man with that much exposure in the world still has the guts to publicly say something (or should I say nothing?) like that.

EDIT: SCO have now pulled the first link, only 10 minutes after I posted this blog entry.  No surprise there! 

Well, now this is funny.  I'm busy working on a web project which means I need to test the site in every possible browser, including the latest-and-greatest offerings from the likes of Microsoft and Mozilla.  I decided to grab the latest public build of Internet Explorer 8, and Release Candidate 1 was just announced a few days ago.  I'm thinking "Good timing!"  With Windows 7 Beta Build 7000 officially "out in the wild", I expected it would be a painless install..

Instead, I received this error message when I started the installation app in Windows 7.

 

This deserves a LOL. I'll have to Google around (sorry, Microsoft) for an answer to this one!

Back to work!

 

 

http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Meijer-and-Chrysanthakopoulos-Concurrency-Coordination-and-the-CCR/

The above URL is a link to a video on Microsoft's Channel 9 site which really gets into the nitty-gritty world of programming from all perspectives.  You have to be REALLY into programming to understand even 10% of the things that George Chrysanthakopoulos says, but if you DO understand that 10% it is definitely worth watching!

It's videos like this that make me proud to be a developer in this constantly changing world of software development.