TechFest Houston Slides and Source Code


Published Monday, September 28, 2009 | Comments (1)

TechFest Houston was a blast, and if you came out to my presentation on Simpliyfing Web Part Development or dropped by the Cogent booth, then I would like to say thank you! The presentation slides and demo source code can be downloaded below.

Simplifying Web Part Development.zip (2.35 mb)

.NET on the iPhone?


Published Friday, September 18, 2009 | Comments (0)

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.

Access Denied for "User Profile and My Sites" Links in an SSP


Published Friday, September 18, 2009 | Comments (0)

SharePoint is great about hiding permissions.  I was working on a Shared Service Provider (SSP) and was greeted with an access denied page when I went to edit some of the profile settings under the "User Profile and My Sites" section.  I was a little disturbed because I am a site collection admin, and I have access via the Web Application Policy in Central Admin.  Fortunately, I found the following link:

http://blog.tylerholmes.com/2008/09/access-denied-for-site-collection.html

Tyler Holmes was nice enough to post his findings and provide a nice walkthrough on how to get around the issue.  Basically, it involves clicking on the permissions link at the bottom of the "User Profile and My Sites" section and giving yourself access.

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: SharePoint

VSeWSS 1.3 - Getting around the "Unable to load one or more of the requested types" Error


Published Monday, September 14, 2009 | Comments (0)

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. 

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: none

Speeding up Windows Virtual PC Performance (on Windows 7)


Published Tuesday, September 08, 2009 | Comments (0)

I recently upgraded to Windows 7.0 and I have to say that I'm liking it and it's a heck of a lot better than Vista.  I can't really put my finger on it, it just seems easier to navigate through stuff and get to what I want.  But one of the things I found disappointing was the performance of Windows Virtual PC, which is currently in Release Candidate (as of this posting).  I've got a nice machine with a quad-core and 8 gigs of RAM, and VPCs in the past have been like working directly on another box.  But even with the RAM maxed out for a VPC, the VPC machine was running horribly slow.  I soldiered through working on a VPC for a night, and I think it took about 8 hours to do about 2 hours worth of work.

In the end, I moved the VPC from my host drive (C:) to a USB 2.0 hard drive.  It was like day and night - the VPC was back to running at full speed.  I'm not sure why having the VPC image on your host drive is such an issue (it wasn't in Vista), but if you're having performance issues with VPC on Windows 7.0, I highly recommend moving the image.

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: Technology

Disable XML Comment Warnings for a File


Published Friday, September 04, 2009 | Comments (0)

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:

// Disable all XML Comment warnings in this file //
#pragma warning disable 1591

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.

Fixing the 'Name ActiveX Control' Message on SharePoint Sites


Published Friday, September 04, 2009 | Comments (0)

SharePoint sites normally have a 'Name ActiveX Control' used to communicate you're online presence back to the Office system.  If you've ever seen a site where it shows you who is 'online' and who is 'offline' then know that this is the mechanism that marks someone as being 'online'.  That is all fine and well for internal application, but it kinda sucks for public facing sites because users are asked to install some weird ActiveX control that they know nothing about.  I find it particularly odd that it's included on the default publishing site.  Whatever.  Fixing it should be relatively easy because there is a knowledge base article outlining what to do:

Knowledge Base Article 931509

Unfortunately, that only gives you part of the solution.  It basically tells you to comment out two function headers in the init.js file.  If you follow the instructions in the Knowledge Base article exactly, you'll see a little JavaScript error notification when you refresh the page.  Probably because, now, let me guess . you commented out a function header without commenting out the rest of the function?  Also note that one of the functions you commented out gets called later, which is a bit of a syntactical no-no in just about every language of which I can think.

So, if you want to avoid the 'Name ActiveX Control' message on your SharePoint site AND have it work correctly (novel idea), you need to entirely comment out both functions, and comment out any references to those functions anywhere else in the JavaScript file.

Avoiding Local Authentication Issues with SharePoint Sites using Host Headers


Published Wednesday, September 02, 2009 | Comments (0)

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.

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: none

Recursive Anonymous Methods


Published Tuesday, September 01, 2009 | Comments (0)

I was having a lively discussion with a friend the other day on the finer points of anonymous methods and lambda expressions. Yes, at Cogent Company this is actually what we do for fun.  I had basically said that an anonymous method was just like any other method, to which he rattled off a laundry list of the differences.  One of those differences caught my attention:  you cannot create a recursive anonymous method.  At first glance it seems to make perfect sense - how can you call a method with no name.?  But when you think about it from a CLR perspective, how could you not be able to?  An anonymous method is basically like any other method, and if any other method can be called recursively then so can an anonymous method.

So, here's the code for a recursive anonymous method that solves factorials:

using System;
using System.Reflection;

namespace RecursiveAnonymous
{
 
class Program
  {
   
delegate int FactorialDelegate(int i);

   
static void Main(string[] args)
   
{
      FactorialDelegate factMethod
= x =>
       
{
         
return x <= 1 ? 1 : x * (int)MethodBase.GetCurrentMethod()
           
.Invoke(null, new object[] { x - 1 });
       
};
     
for (int i = 0; i < 10; i++)
     
{
        Console.WriteLine
(factMethod.Invoke(i));
     
}
      Console.Read
();
   
}
  }
//class
} //namespace

The real trick is to use MethodBase.GetCurrentMethod(), which gets a reference to the MethodBase of the currently executing method (essentially the MethodInfo).  From there you can call the .Invoke method and pass in the appropriate parameters, allowing the anonymous method to execute again (recursively).  Hooray for reflection.

I have no idea why anyone would want to do this, aside from settling bets or showing off, but it's nice to know that you can.  As for my buddy, he says I cheated.  To which I can only reply, damn straight! :)

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: .NET Development

Avoid Parenthesis in VS 2005/2008 Web Site Project Paths


Published Saturday, April 19, 2008 | Comments (0)

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.

Bookmark this post: Dot Net Kicks
By Damon Armstrong | Permalink | Comments (0) | Comment on this Post
Filed Under: none