Visual Studio Extensions for Windows SharePoint Services 1.3 (VSeWSS 1.3) tends to make my life easier unless I'm typing out the words that make up the VSeWSS acronym - really, what a mouthful.  But one of the problems that I routinely encounter are error messages when trying to deploy solutions.  These normally look something like the following:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

I tried a variety of steps to resolve this issue:

• Recycling the application pool
• Restarting IIS
• Closing Visual Studio
• Not detaching from the debugger until a request was fully completed
• Logging off and logging back into Windows
• etc.

Nothing actually worked.  Some of these resolution attempts seemed to help keep the problem from happening quite as frequently, but I still have no idea what EXACTLY causes the problem and it would rear its ugly head from time to time.  Unfortunately, the only resolution I found that seemed to work was to reboot the machine . which is a crappy resolution.

Finally sick enough of the problem to spend some time on it, I went on a search and tried to figure out if anyone else was having this issue.  People seem to suggest that turning off the Indexing Service on your machine helps resolve this problem.  I tried turning it off but I kept having issues.  Which was depressing. 

Fortunately, I stumbled upon the resolution when I was looking through the services list.  If you encounter the issue, all you have to do is reset the World Wide Web Publishing Service.  I've had a 100% success rate so far with this approach.  I'm not sure if having the Indexing Service is part of the solution, but I've kept it disabled for the time being because I'm really sick of having to reboot my machine to deal with that error message.

If you do VSeWSS development, you may also want to check out this blog post:
VSeWSS 1.3 - Getting around the "Unable to load one or more of the requested types" Error

Ty Anderson just shot me a link to MonoTouch (http://monotouch.net/), a product that allows you to develop IPhone software using Microsoft's .NET Framework.  You'll still need a Mac, the Apple iPhone SDK, and to be a member of the Apple iPhone Developer Program, but it's still pretty cool that it lets you use your current knowledge set to develop applications.  At least in theory.  Not sure how that works out in reality, but I'd be interested to see and hear if anyone has/is giving it a shot.

I hate packaging SharePoint solutions by hand.  Once you've got it working, it's not a big deal, but it takes a lot of reading and remembering each time you start one anew.  VSeWSS is a nice tool that integrates with Visual Studio 2008 and builds out SharePoint solution files auto-magically.  However, it has its quirks.  Quirks that irk me to no end because it feels like it's a constant struggle to get it to do what you want. 

I've got a templated web part base class that I use on a lot of SharePoint projects because it really helps separate out the UI from the business logic.  In the past, we've just copied the code from project to project.  In an attempt to avoid code strewn about all over the place, I decided to pull it back into a single assembly where it could be maintained more easily.  So, after a bunch of work, I went to package things up with VSeWSS and I received the following error:

VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Wonderful.  A bit of digging revealed that this is an issue if you're web parts reference a base class in another assembly.  For real?  Seems like that's a pretty big issue since copying and pasting code from project to project is frowned upon in terms of maintainability. 

Then I used all of my mental devices and .NET knowledge to create a plan so cunning that it would circumnavigate the issue entirely.  Make an dummy class in the project that inherits from my base class in the assembly.  As such, the base class would be in the project itself where VSeWSS could see it, but the REAL code would be in the external assembly.  Shear genius!

Yeah, that didn't work.  Apparently you can't have a base class ANYWHERE in the inheritance chain.  That left me with a big WTF moment.  I was seriously miffed that this would not work.  If you look into the error that VSeWSS throws, you'll see it's a reflection error.  So I hashed together my next, slightly less cunning, plan:  throw copies of my assembly everywhere and anywhere that VSeWSS could be looking in the hopes it would magically find it.  I ran the VSeWSS packager, and it packaged everything up without error.  So then it was a process of elimination as I removed the assembly from the various places I had placed it.  In the end, I found that in order for VSeWSS 1.3 to see your external base class, you need to copy your assembly to the following location:

C:\Program Files\Microsoft SharePoint Developer Tools 9.0\svc\bin

This appears to have worked for my scenario, though I'm not sure if such is always the case.  I was also really surprised that putting the assembly in the GAC seemed to have no effect. 

I'm a big fan of enabling XML comments when you're working on a project (either alone or as a team) because it helps you quickly identify what has and what has not been documented.  When you have XML comments enabled, the compiler will show warnings for any public and protected classes / class members that do not have XML comments.  To enable XML comments you just check the XML documentation file option in the build tab of the project properties page. 

One of the issues that you run into, however, is that there can be a number of code generated files in your projects, and you have no control over that code.  But, if that file is no re-generated often, then you can insert a bit of code to suppress XML comment warnings from that file:

The next time you compile, XML comment warnings from the file will not be display.  If you're wondering, the 1591 is the specific warning number for XML comments.  If you remove the XML comment warning number from the pragma statement, then all warnings from the file are suppressed, not just XML comment warnings.  no warnings will come from the file.  You can also tack on additional warning codes to suppress additional types of warnings, if desired.  How do you figure out what the numbers are?  I find one of the easiest ways to go about it is to read the output window (NOT the Error List window).  When a warning is generated, it normally looks something like the following:

[filename]: warning CS1591: Missing XML comment for publicly visible type or member 'VSeWSS.TargetListAttribute'

Notice there is a number right after the warning (in this case its CS1591)?  Just drop the alpha prefix and you've got your warning number.  Since this is in the output window, you may have to scroll through the text a bit to actually find the warning, but it should be in there somewhere.

All of my VPCs are children from a base VPC that I happened to name Win2k3R2Base.  At the time, it seemed pretty reasonable because I was building a base VPC for Windows 2003 R2.  But when you're developing SharePoint web applications, it gets pretty tiring having to continually type a nasty machine name into URLs.  So I figured I would use a host header instead of the machine name to access the SharePoint site. 

After setting up a site to use a host header, however, I ran into an issue authenticating to the site.  It kept prompting me for a login and, although I was typing the correct username and password, authentication always failed, giving me the standard:

HTTP 401.1 - Unauthorized: Logon Failed

I did a bunch of checking to make sure the host headers were setup correctly, the alternative access mappings were pointing to the right place, that the host name would resolve to the right IP address, but no matter what I did, I could not access the site from the local box.  Interestingly enough, I could access the box externally using the host header without any issues (after updating the other box's host file).  Naturally, this was a bit perturbing. 

I figured there had to be a solution for this somewhere, so I began scouring the web looking for a solution.  After a bit of searching, I found the following Microsoft Knowledge Base (KB) article that outlines the problem:

http://support.microsoft.com/default.aspx/kb/896861

Basically, there was an update in Windows Server 2003 Service Pack 1 that adds a loopback check to help prevent reflection attacks on your computer.  Fortunately, there is a simple registry edit to avoid the loopback check on certain host names (the recommended approach) or a way to simply disable loopback checking altogether (not quite as a recommended).  Try one, and if it doesn't work, try the next.

I was developing against a web site project -- you know the ones in Visual Studio 2005/2008 where you can just point to a directory and do your thing (as compared to a web application project with an actual project file) -- and I noticed something a bit odd.  When I compiled the project the Error List was not showing file references, line numbers, columns, or any other information about the location of the compiler errors. 

I figured Visual Studio was just getting tired since it had been open for days, so I restarted the application in hopes that it would straighten out.  No such luck.  Then I restarted the computer.  That's what tech support normally recommends anyway, so I figured I'd start with the basics.  Once again, no error location information. 

At this point, I was starting to wonder if it was an issue with Visual Studio 2008 that nobody had noticed yet.  Of course, if VS 2008 wasn't showing error location information on web site projects then there probably would have been an outcry long before this.  So I hit the search engines. 

It was a pain to find, which is why I'm trying to help publicize the issue, but there are a few references to the exact issue I was having.  Specifically on the following sites:

http://www.developmentnow.com/g/51_2006_7_0_0_790825/Errors-in-Error-List-with-no-line-numbers.htm

http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-net-ide/4006/Error-List-Missing-the-Code-File-Reference

What was the problem?  I was using parenthesis in the path to the web site project.  After removing the parenthesis, the problem was gone.

I had the code base for my first WPF application ready to go, so I compiled a release version of software and tried to run it from the .exe instead of directly from Visual Studio.  I was promptly greeted with the following error:

The tag 'WindowsFormsHost' does not exist in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml/presentation'.

It ran flawlessly from the Visual Studio .NET debugger, which I found a bit odd.  I tracked the issue back to the following problem.  When I originally referenced the WindowsFormsIntegration.DLL from my project, the "Copy Local" option was set to false.  When I went back in and set that value to True, the application promptly broke when it ran in the debugger.  I don't mind when things break as long as they break consistently, so this was a step in the right direction.  I had found a few helpful forum entries informing me that you have to specify the xml namespace for the WindowsFormsIntegration assembly.  So I added the following xmlns entry:

xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"

And changed my WindowsFormsIntegration tag from

<WindowsFormsHost>
    ...
</WindowsFormsHost>

to

<wfi:WindowsFormsHost>
    ...
</wfi:WindowsFormsHost>

and it started working just fine.

I've been working with a number of XML documents recently.  Basically I'm trying to expose configuration values stored in XML configuration files in an object-oriented structure.  I'm using an in-memory XML document and just referencing values as needed from that document.  The XML reading does not need to be super-high performance because it does not occur very often, but it got me to thinking... what if it did?

So I ran some performance tests to check the difference between accessing a value from an XML document vs. storing the value in cache and accessing it through a standard get property. 

The results (at least on my machine) are as follows:

I knew caching would beat out the other two methods since it's very fast to access a direct variable, but I was surprised that there was such a difference.  I figured there would be a bit of overhead for the inner text property, and a bit more for the attribute lookup, but I was thinking it would be in the range of 10-20% slower.  Live and learn.  Of course, reading from an in-memory XML document is still pretty dang fast, it's just that reading from a cached value is faster.