PLINQO! (No, not the game on Price is Right.)

My friend Tyler introduced me to PLINQO, a killer looking LINQ to SQL ORM data layer, for a side project I'm collaborating with him on.

I'm total newb to it, but I drooled when he gave me a quick crash course on how it works. It's giving me a wonderful opportunity to brush up on the LINQ skills and remember why I love .NET development so much.

I'm excited to see how it plays out for me... if I like it enough, I'll start using it in my own personal projects.

One thing I've been impressed with in the VERY short time I've used it so far, is how easy it is to pick up and run with.

How can you not like this:
public string[] GetStateEmployeeNames( int stateId )
{
string[] stateEmployees = (
from se in this.DataContext.StateEmployee
join e in this.DataContext.Employee on se.EmployeeId equals e.EmployeeId
where se.StateId == stateId
orderby e.Name
select e.Name).ToArray();

return stateEmployees;
}

It's goodness... I can't wait to see what other ease and power PLINQO will offer. Stay tuned...

Ensure XHTML Strict Compliance by Removing Name Attribute from Form tag in ASP.NET

Many of us web developers are trying to be "good citizens" and conform to the higher standards of XHTML in our apps.

By default, ASP.NET will add the name="FormName" attribute to the rendered XHTML.

To force ASP.NET to omit the name attribute, simply add the following tag to the system.web section of your web.config file for your app:

<xhtmlConformance mode="Strict" />

Be warned, however; unfortunately it doesn't seem to make ASP.NET render HyperLinks properly. I have an asp:HyperLink that happens to have an ampersand (&) in the Text and ToolTip properties. The ToolTip properly renders a title="" attribute with the ampersand encoded as &amp; ... but the text between the open and close <a> tags doesn't have the ampersand properly encoded.

The only advice I can give you there is to:
1. Use the word "and" instead of an ampersand
2. Make static "a" tags instead of using the ASP.NET HyperLink object, if you can. If someone knows a smoother/quicker/more elegant solution, please leave a comment with it!

"The breakpoint will not currently be hit" "The source code is different then the original version"

Today, I was debugging an ASP.NET website. I was at a breakpoint when a co-worker called me over to their desk to help with a defect they were trying to reproduce.

I needed to use remote desktop to look at something on my own machine, so I did so. While I was accessing it via remote desktop, my Visual Studio decided to crash.

Aftwerward I started seeing the following on breakpoints I was trying to hit:
"The breakpoint will not currently be hit. The source code is different then the original version"

I thought that a reboot would help, but to no avail.

After talking to another co-worker that had seen it in the past, he informed me that he fixed it by deleting all of the Temporary ASP.NET Files.

Sure enough, it worked like a champ. However, I had to shut down anything that had handles on those files (like the ASP.NET development server, Visual Studio, etc.) before I could complete the delete.

So to fix the problem:

1. Close out Visual Studio and make sure any instances of ASP.NET development server are closed as well.
2. Delete everything from "C:\Windows\Microsoft.NET\Framework\v.2.0.50727\Temporary ASP.NET Files" (where v.2.0.50727 is the version of the .NET Framework your site is running on.)

Hope this helps someone else... it sure helped me.

Error connecting to undo manager of source file "whatever control/page.designer.cs"

I've run into this problem a couple of times where I get an error that states:
Error connecting to undo manager of source file "MyControl.ascx.designer.cs" (I've seen it with an aspx.designer.cs too.)

I don't know what the cause is, but I have a sneaking suspicion that the culprit in both of my cases was merge operations from source control interactions where, for whatever reason, my designer became out-of-sync or something with its ascx/aspx counterpart.

After searching around the net, it seemed the most popular method of correcting the problem was to delete the designer completely, then run the option to convert the project to a Web Application.

That option didn't sit right with me. I searched on.

I found an article by Scott Hanselman that discussed excluding the designer from the project, recompile, re-include, recompile again. That seemed a much more fitting solution to me; but I wondered if it could be even easier. So I tried an experiment.

My experiment consisted of simply opening the designer.cs file, typing a character somewhere in the file, deleting the new character, saving the file and recompiling.

The problem disappeared for me after that. (I will note that I cleaned the solution and rebuilt it prior to trying this, and that may be a required piece of the solution to the problem, but I would try the simple step first, then add in the clean/rebuild after.)

I'm using Visual Studio 2008 SP1. I hope this helps someone else out there.

ASP.NET Development Server Responds with 403 - Forbidden in Firefox

I've been working on an ASP.NET site for a few months that requires Windows Authentication, and it was working fine when running the site in the ASP.NET Development Server and accessing in Firefox.

That is, until today.

Today, it decided to start kicking back Forbidden messages every time I tried to access it. Why would it start doing that to me?

It turns out I had at some point told Firefox to remember the password for the site, then had to change my domain credentials after doing so. Since my saved password didn't match the new password, the site was forced to return a Forbidden. I would hope that Firefox would prompt me for a new password when the authentication failed, but it didn't.

So how do we get back to good in Firefox?
You have to go into the Saved Passwords settings in Firefox and remove the site from the list of passwords to store.

In Firefox 3:
Tools | Options
Click on the "Security" button on the ribbon at the top of the Options dialog

Click the "Saved Passwords..." button in the "Passwords" section of the "Security" tab.
Find the offending site in the "Saved Passwords" dialog and click the "Remove" button.

Click "Close" on the "Saved Passwords" dialog.
Click "OK" on the Options dialog.
Open the site again and Firefox should prompt you for the new credentials.

Hope this helps!

Why We Must Use Classes Instead of Structs for Read/Write DataBinding in C#

Structs are Value Types.
Classes are Reference Types.

When we DataBind in C#, if we're using Value Types... we get copies of those objects instead of pointers to them, for that's how they are passed to the bound control. Therefore, you can't edit the bound control and expect the original objects to be modified. The bound control is only editing the copies and thus we encounter side effects when DataBinding a list or array of value types (like structs.)

I ran into this on a project I was working on where I needed to show a DataGridView for editing attributes. My attribute representation was a struct with a name property and value property... and when I bound a BindingList to the DataGridView, the list would appear... but when I'd edit the values would return to the old values... and when I'd add rows, the values would disappear.

The explanation above explains why. It didn't dawn on me until I started searching for "BindingList structs" and found Bill Wagner's "Of DataBinding and Value Types" (archive.org since the site is no longer available). The title tipped me off because I wasn't thinking about the fact that structs are value types.

Bill's article explains in more eloquent detail than I care to go into here, as I don't feel the need to re-write a well written essay on the topic. I only hope to provide a quick answer for those searching for it, that don't find Bill's article first (and leave myself a quick reference when I forget the next time I try to use a struct...)

He also mentions in his article when it is appropriate to use structs. Thanks for a well-done article, Bill.

So, reminder: use classes instead of structs when you need to do read/write binding. If you're merely databinding for a viewable list... use structs as you like.

ASP.NET - Getting the Virtual Application Root Path for Your Site

HttpContext.Current.Request.ApplicationPath

I had to blog this here, because I have the need for it every once in a while, but not frequent enough to remember it... :)

Examples:
A site hosted without a virtual directory: mysite.com/
Returns: "/"

A site hosted from a virtual directory: mysite.com/myVirtualDir
Returns: "/myVirtualDir"

See the MSDN Documentation for more details and code examples.
See the "ASP.NET Web Site Paths" article for more ways to discover paths.

Make Visual Studio Prompt You For Debug Source Code File After Cancelling the First Time

I've run into this problem a few times where I've been given a copy of a dll from another development team that has a PDB file with it... but they forget to send me the source code...

While debugging, I get the prompt for the source code file the PDB has signalled the debugger for (since it doesn't know where to find it initially...) and of course, since I don't have it, I click Cancel.

When you click cancel at this prompt, it adds to a repository in the solution of files NOT to search for. This is annoying, because after that first prompt, you ask the team for the source code so you can go back, expecting the prompt again, and step into the potentially problematic code.

Well, Visual Studio supresses the prompt because of this list within the solution of files not to search for.

"How do I get this back?!" you ask...

Here's the "solution" (get it?!):



Right-click your solution in Solution Explorer and go to Properties.
Then click on the "Debug Source Files" section under Common Properties.
At the bottom-right of the dialog, there is a "Do not look for these source files:" section. There lies the last-known path to the source-code file (which I assume is provided by the PDB.)
Delete that sucker and Apply/OK out.

Debug again and when you get to the point you want to step into that code again, you will get the prompt and life will be happy again (well, happier, until you fix your bug.)

Happy coding...

How to Make Visual Studio 2008 Continue After an Unhandled Exception

I was debugging an app that was not handling a particular exception; and I found that after the Exception Assistant dialog appeared and I hit F5 to continue, that it would repeatedly recall the offending line of code which would again throw the exception.

I searched the net and found this forum thread on MSDN that shed some light on how to allow the program to continue after the exception is thrown.

Tools >> Options >> Debugging >> General
(General options show if you only go to Debugging)

Uncheck the "Unwind the call stack on unhandled exceptions" to prevent the debugger from reverting to the offending line as the next statement to call.

Compatibility Tag for Internet Explorer 8

Microsoft emailed me today to warn me that Internet Explorer (IE) 8 will now be in "Standards Mode" by default instead of the "Compatibility" (sometimes referred to as "Quirks") mode the older versions have run in.

This means that web developers that may have sites out there with invalid markup may run into some issues for people viewing their sites using IE 8.

This is a GOOD thing Microsoft is doing, as it will make their browser play more like the others that are in "Standards" mode by default.

The email Microsoft sent me is to inform developers that they're not left in the dark. Microsoft has offered a way to make the sites tell IE to go back into "Compatibility" mode so it will look the same as it would in IE 7 or earlier.

NOTE: This is not an excuse not to fix your markup!!! You still need to fix your sites to be compliant with standards... this will just buy you some time until you do.

Go to Microsoft's article to find out how to use this compatibility tag should you need to.

Make sure to download Internet Explorer 8 beta and see if your sites may need this tag... your site will render differently in IE7 and IE8 if you do; if they look the same, you're a good developer! :)