Attached is a simple contact generator (And source) that creates random contact data in CSV format. The data generated, although random, is pretty realistic as address and phone numbers correspond correctly and other values are sampled from a realistic set of data. The data generated appears as follows:

"Index","Id","FirstName","LastName","FullName","Username","Username2","Password","Email1","Email2","Phone1","Phone2","Fax1","Fax2","Address1","City1","State1","Zip1","Address2","City2","State2","Zip2"
"1","{c0d4079c-50c7-4214-a094-b09d51b9d143}","Raven","Huddle","Raven Huddle","rhuddle","raven.huddle","13af04ae","raven.huddle@aol.com","raven.huddle@earthlink.net","(303) 998-8084","(718) 229-7963","(303) 998-5593","(718) 229-4928","84596 Brimm BLVD","Boulder","CO","80302","36863 Noakes LN","Flushing","NY","11364"
"2","{74e80927-a654-4010-9020-7098452b4193}","Rhonda","Reitz","Rhonda Reitz","rreitz","rhonda.reitz","3282e152","rhonda.reitz@btinternet.com","rhonda.reitz@verizon.net","(907) 252-0297","(703) 242-6715","(907) 252-0163","(703) 242-9363","89079 Sterrett PL","Soldotna","AK","99669","41346 Mccauley HWY","Vienna","VA","22181"
"3","{742a3ad4-e1e8-44ed-a6a0-1654981e0c9b}","Ruth","Mcnemar","Ruth Mcnemar","rmcnemar","ruth.mcnemar","16548a78","rmcnemar@aol.com","rmcnemar@verizon.net","(305) 541-2410","(704) 892-5466","(305) 541-4633","(704) 892-3899","93562 Bruno BLVD","Miami","FL","33129","45829 Meadowview HWY","Davidson","NC","28036"
"4","{d72fb280-66cf-49a8-81bb-f5da4a096614}","Jimmy","Kizer","Jimmy Kizer","jkizer","jimmy.kizer","3528671c","jkizer@verizon.net","jimmy.kizer@earthlink.net","(704) 854-4523","(734) 797-4218","(704) 854-9102","(734) 797-8335","98044 Meadows HWY, Suite 370","Gastonia","NC","28054","50311 Pamona LN","Livonia","MI","48150"
"5","{90409c90-c967-4b1f-b66c-6b9f31043303}","Kiehl","Gillum","Kiehl Gillum","kgillum","kiehl.gillum","18fa1042","kiehl.gillum@gmail.com","kiehl.gillum@rediffmail.com","(320) 679-6636","(810) 863-2970","(320) 679-3672","(810) 863-2871","2578 Claywood BLVD","Mora","MN","55051","54794 Rockledge PKWY, Suite 945","Roseville","MI","48035"
"6","{f47a479c-d0a9-43d8-84aa-97970b0c4892}","Walletta","Spivey","Walletta Spivey","wspivey","walletta.spivey","37cdece6","wspivey@hotmail.com","wspivey@bellsouth.net","(218) 723-8749","(650) 357-1721","(218) 723-8142","(650) 357-7306","7061 Baypointe AVE","Duluth","MN","55802","59277 Mack HWY","San Mateo","CA","94403"
"7","{f2b1687a-78ce-437b-baa0-2b959ee260d5}","Chauncey","Slemp","Chauncey Slemp","cslemp","chauncey.slemp","1b9f960c","cslemp@comcast.net","cslemp@charter.net","(412) 393-0962","(916) 492-0473","(412) 393-2712","(916) 492-1842","11544 Dumesnil CIR","Pittsburgh","PA","15222","63760 Tiburon PL, Suite 814","Sacramento","CA","95814"
"8","{19189dab-e300-42d2-8580-c4216fcaafb3}","Roxanne","Bond","Roxanne Bond","rbond","roxanne.bond","3a7372b0","roxanne.bond@msn.com","roxanne.bond@aol.com","(336) 506-3075","(308) 652-9124","(336) 506-7181","(308) 652-6278","16027 Continental CIR","Burlington","NC","27215","68242 Burning BLVD","Orleans","NE","67647"
"9","{7703a831-1f56-43cd-87ea-c998fcb52682}","Elvie","Cissell","Elvie Cissell","ecissell","elvie.cissell","1e451bd6","elvie.cissell@charter.net","ecissell@cox.net","(917) 344-5189","(770) 242-7876","(917) 344-1751","(770) 242-0814","20509 Tivoli RD, Suite 491","New York","NY","10041","72725 Perlman LN","Norcross","GA","30071"
"10","{0aed5fd3-70e8-41e0-bbc4-418d122a590b}","Newman","Peters","Newman Peters","npeters","newman.peters","216c4fb","npeters@earthlink.net","npeters@hotmail.com","(719) 530-7302","(281) 944-6628","(719) 530-6221","(281) 944-5249","24992 Oak LN","Salida","CO","81201","77208 Bolsa BLVD","Houston","TX","77037"

Installer: SetupContactGenerator.EXE (833.81 KB)

Source: ContactGeneratorSource.zip (584.5 KB)

I must say, the OOB development experience in SharePoint has been less than desirable. I feel like MS has given us a number of tools but left us in the lurch figuring out how to use them, and its not always obvious how. One thing I have wanted to do is use the designer to develop web parts and deploy them with the click of a button. The VSeWSS have made the "deploy with the click of the button" part possible but the designer part has not been so obvious. How can you marry a designer experience with the VSeWSS ease of solution deployment? I'll show you how...

For Starters

The following information utilizes the Visual Studio Extensions for WSS (VSeWSS) which can be downloaded here. VSeWSS only offers a subset of the features available with solution deployment but offers "one touch" deployment OOB. Creating your own solutions manually will give you more options but may be more work than its worth (Unless you have found some nifty 3rd party tool or created your own). So the following information will strictly use what VSeWSS has to offer. VSeWSS can only run on a Windows Server 2003 box with MOSS 2007 & Visual Studio 2005 installed (Although it can be hacked to run on XP, most of the features do not work). VSeWSS may have problems if MOSS 2007 was not installed as a standalone server, so says the download notes and my experience with it. Although I have a colleague who has used it in a farm configuration and not had an issue.

Creating a blank VSeWSS Project & Web Part

Obviously you cant use the designer with a web part but you can with a Web User Control (This is the thought behind SmartParts). So lets start off by creating a project from an empty VSeWSS template.

Next add a new Web Part from the VSeWSS templates.

Now your probably thinking "Now add a Web User Control, yada yada yada", right? Wrong! If you have gone down this path before you will probably discover a couple of things; first the Web User Control is not available as a new item in a VSeWSS project. This can be worked around fairly easily by modifying the templates available to the class library project type or by creating the user control in a Web Application Project (WAP) and copy the files over, either way hacky. Second, you will discover that the designer does not behave as it does in a WAP or web site. For example your code behind and designer classes are not linked together and when you double click a control the default event code is generated in the ascx file instead of the code behind. This and a number of other quirks render this method almost as bad as just coding your entire control in the Web Part (Almost, but not quite). So how do we get the designer to work properly? .

Creating a hybrid VSeWSS/WAP Project

We need to create a hybrid VSeWSS/WAP project. This requires that you either have VS2005 SP1 installed or the WAP extensions installed (If you decided not to wait 5 hours for SP1 to install...). In order to make your VSeWSS project also a WAP project you will need to adjust the project type in the .xxproj file. To do this, right click the project we just created an select "Unload Project". It may ask you to save, press yes.

Once the project is unloaded, right click it again and select "Edit xxxxxxxxxxx.xxproj".

Once you have opened the project file you will need to add in the WAP guid into the ProjectTypeGuids element under the first PropertyGroup. This guid, {349c5851-65df-11da-9384-00065b846f21}, should be the second guid in the list (Shown in bold/green below), the first one being the VSeWSS project guid. All the guids in this element should be separated by a semicolon as shown below.

 After this has been set, right click the the project again and select "Reload Project". Click yes to save when prompted.

Now close out of Visual Studio, save your project when prompted. Restart Visual Studio and open your project.

VSeWSS Deployment

Now your probably thinking "Now add a Web User Control, yada yada yada", right? Well, yes, you can now add a Web User Control and its designer will work properly. But we want to be able to deploy it strictly with VSeWSS and its solution builder. In order to do this we will need to install the user control with a Module, so lets do that first. Right click your project and add a new Module. I will generically call it UserControls as I will want to add more user controls to it as I add web parts.

Once your module is created you can delete the "sample.txt" file from the UserControls folder. Now right click the UserControls folder and click Add --> New Item and select the standard Web User Control.

Next open the module.xml in the UserControls folder and add a reference to your newly created user control.

The Url attribute in the Module element specifies the relative path on the SharePoint site where the file will be deployed to. In this case I chose a sub folder called "UserControls".

Creating the User Control and Linking the Web Part

Now, add a label to your User Control called CurrentTime (Or whatever you want to call it...). And set it, in the control load event, to the current time.

Since the VSeWSS Solution Builder creates a solution that installs only the project assembly to the GAC (Which is lame indeed) you will need to add an assembly directive to the user control, before the control directive is defined. If you do not add it before the control directive your control will fail to load as it will not have a reference to the project assembly in the GAC.

To obtain the public key token you can run the sn.exe utility in the SDK with the -T parameter and the path to the assembly. For example:

Next, override the CreateChildControls method of your web part and load the user control with the Page.LoadControl method. UPDATE: Thanks to Charles for pointing out that you also need to remove (If your not using it) the default Render(...) override. The WebPart template has this defined and by default it does not call the base implementation so ya get nothing displayed!

Now hit F5 and deploy!

As you can see, this method gives you the benefit of the designer and VSeWSS solution deployment. The full source of the sample can be downloaded here:

Normally I like to create a stand alone, abstract BLL assembly that can be used by multiple components (ASP.NET, WinForms, Windows Service, etc), nothing new, standard procedure. Well the VSeWSS Solution builder will only load and reference the VSeWSS project assembly in the SharePoint Solution. Pretty lame if you ask me! You would think that it would package all referenced assemblies not just the project assembly, how hard is that?? So you ether have to house all your code in the VSeWSS assembly or deploy referenced assemblies separately to the SP web front ends. If you forget about this, any code that tries to call code in the referenced assembly will throw a generic "File Not Found" exception in SP.

I sincerely hope there is a newer version of VSeWSS coming down the pike. It has the potential to be a really great tool for SP development but the limitations I keep encountering are seriously lessening its value. This is just another example of that.

At some point you may want to define an "icon" for your SharePoint list templates. Doing this is kindof quirky and the SDK doesn't seem to mention the quirk (At least I couldn't find it anywhere).

Basically icons will appear in a few places, for example the Create page when you hover over the list and the the site content summary page.

You can define an image to be displayed in the VSeWSS Solution Properties as shown below:

Here I am referencing a 16x16 png called INotice.png. Now for the quirky part... The image path set above will be referenced as-is in the site content summary page (The first image show above) where the small image (16x16) is used. But how do you define the larger image (32x32) used in the Create List form (Show above)? Basically the Create List page takes the url entered into the list Element Manifest Image property above (Which corresponds to the Image attribute of the ListTemplate element in the List template manifest file) and replaces the first letter of the filename with an "L". So it would change the image url above to "/PhvenEleaseResources/LNotice.png". In this case you would see a broken image link when you hovered over your list template.

So you need to deploy 2 images, first a small image (16x16) with some arbitrary prefix character like "I" ("I" is the prefix used by OOB small SharePoint images, but it can be any character), for example "IMyListImage.gif". Set the Image URL in the VSeWSS list element manifest (As shown above), for example "/MyImages/IMyListImage.gif". Additionally, deploy a large image (32x32) that has the same name as your small image but starts with an "L" instead, for example "LMyListImage.gif". SharePoint will then correctly display the large and small images appropriately.

Now, you may be asking, how do I deploy those list images using VSeWSS and Solution Deployment? The best way I could find (Using only VSeWSS) is to create a module. 

Once created, remove the sample file and reference from the new module. Copy your list images into the the new module folder and reference them in the module definition as demonstrated below.

<?xml version="1.0" encoding="utf-8"?>

<!-- _filecategory="Module" _filetype="File" _filename="module.xml" _uniqueid="7d203b86-3fe2-46cb-ba36-bb255430ce6f" -->

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

    <Module Name="MyImages" Url="MyImages" RootWebOnly="TRUE">

        <File Url="LMyListImage.gif" Type="Ghostable"/> <!-- Large image (32x32) -->

        <File Url="IMyListImage.gif" Type="Ghostable"/> <!-- Small image (16x16) -->

    </Module>

</Elements>

Once deployed the two images can be referenced as "/MyImages/IMyListImage.gif" and "/MyImages/LMyListImage.gif" where the Module Url attribute defines the path off the root of the site.

If you have worked with VSeWSS templates you will have probably noticed the comment added to the top of certain aspx/xml files:

First of all don't delete this! This "comment" is actually meta data that enables the VSeWSS solution builder to process the file. The "_filecategory" property identifies the file category (I have a gift for stating the obvious...). It is actually tied the the SolutionElementFileCategory in the SPDevTools.dll library under the Microsoft.SharePoint.Tools.SharePointSolutions namespace.

public enum SolutionElementFileCategory
{
    Unknown,
    SiteDefinition,
    ListDefinition,
    ListInstance,
    Module,
    ContentType,
    Provisioner
}

Next, the "_filetype" identifies the type of file (Duh!) and is tied to the SolutionElementFileType enumeration in the library/namespace mentioned previously.

public enum SolutionElementFileType
{
    Unknown,
    Schema,
    File
}

Next, the "_filename" property tells the solution builder what the name of the file should be in the resulting solution. And last but not least the guid which uniquely identifies the file. Every element in a solution must have a unique guid in order for the solution builder to work with it ("Element" meaning a SP Solution aspx/xml file or a class). Classes are given a unique identifier by defining a Guid attribute to the class. If you copy an existing aspx/xml solution file, as a template for a new file, remember to change the guid. Also if you are copying a solution file as a template for a new module file don't forget to remove the meta data. If you don't, the solution builder will not include it in the module as it thinks the file has another purpose because of the metadata.

Another SharePoint anomaly... Will they ever end??? So I have had this strange issue where doing a deploy of a VSeWSS project does not seem to update the SharePoint site for certain elements like schemas. I have to retract/remove the solution manually from SP, close/reopen Visual Studio (Otherwise I would get a null ref error), then redeploy to see changes. The VSeWSS deploy process does an iisreset (Which I tried manually doing as well) but the updates do not appear without following the steps mentioned. I checked the SP database and SP hive and the elements in question were deployed... So the only thing I could think of is that these elements must cached in memory, which was baffling since an iisreset should clear that out (Right?). Well I finally got the bright idea to verify that iisreset was in fact closing out the IIS service process completely. And lo an behold it was not! After further investigation I found that the “Windows Remote Management (WS-Management)” service, which depends on IIS, was preventing a complete exit of the inetinfo process. I'm not sure what the iisreset was actually doing all along (It said it successfully reset the IIS services), possibly just recycling the AppDomain(s)? But in that case wouldn't SP release cached elements upon termination of the AppDomain(s)? Not really sure, but what I am sure of is that stopping and disabling the the WRM service allowed inetinfo to completely close when the service was restarted by iisreset. And voilà! My changes!

Incidentally I am running Virtual Server 2005 which is monitored by the "Virtual Machine Manager Agent" service. This service depends on the WRM service. So disabling the WRM service will disable your VMMA service. You might want to let your network admin know you need this disabled or it might reappear.

This error almost drove me over the edge... The SharePoint properties pane in Visual Studio would show the error "An error occured trying to load the page. Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)"

After pulling much of my hair out (And doing some trial & error testing) I realized that the problem was that the pane was looking to see if there were any new web parts added to the project each time it loaded. I had added an abstract WebPart base class which some of my other WebParts would inherit from. Problem was this abstract WebPart class was not decorated with the Guid attribute, which is evidently required by the SharePoint property page. I added the Guid attribute and the error goes away.

The only problem is this WebPart base class is now included in the SharePoint Solution as a feature. I haven't found a way as of yet to exclude it.

I have been using @icon sushi for a while now and I have to say its a great utility! Nicely converts .png files (et al), with transparency, to icons and vice versa.

Check it out!

Ah, the joys of learning a new platform! I actually really enjoy learning new things and wish I had the time to learn a lot other platforms/languages. In this case the new "platform" is MOSS 2007. And yes, the more I get into SharePoint the more I feel it is a platform. It's a fundamental shift in so many ways. I have been working on a SharePoint application for about 6/7 weeks now and feel like I'm getting no where. Seriously! I literally have not produced one deliverable. Unfortunately the project was already a year behind when I got on board. The prior developer had left the company and all his work on the project was mothballed in favor of a SharePoint app. So the pressure is on! And this lack of productivity is killing me! If it were an ASP.NET application I would have been light years ahead right now. What's the problem? Well, I don't want to say SharePoint as a technology is the problem. From what I have learned so far, SharePoint is a very powerful technology. Not that it's a holy grail or anything but it is powerful. And from what I have learned, that power is in the configurability and extendability of a platform that out of the box offers a rich feature set. Instead of writing code, I configure and extend. You are configuring an already built enterprise web application, not writing it from scratch. The code you do write extends. Thus SharePoint as a platform.

There are a few things I have learned thus far from this experience. And remember this is from the perspective of building a full blown web application in SharePoint, not just creating and customizing a collaboration site or something high level.

1) Learn the platform well before trying to produce deliverables. One serious mistake I made was trying to produce deliverables (Or promising I would) before I really knew the platform well. I think part of the problem is I didn't realize how big SharePoint was, now I know, it's huge. I feel like a rat that is brute forcing a maze, it will take a long time for him to find the end. How much better it would be if he were to examine the maze from above. Looking back I should have said I needed a couple of months lead time to learn this platform, then I will start to produce deliverables. I would suggest that anyone building applications in SharePoint give themselves sufficient lead time to learn the platform. And I keep saying platform because there is a lot to SharePoint! Get a number of good books and read them (There are new ones appearing weekly), watch web casts, read how to's, setup a mock application to do some hands on work, read blogs of SharePoint users/experts. Spend a good chunk of time learning it first. If possible get training from a place like SP Solutions.

2) Don't let the "this is all you have to do, its so simple!" hype in the documentation and webcasts make you skip point #1. Web casts and how to's want to sell SharePoint as well as try to teach it. They will make everything look so simple! But like any application there is much more to consider at a high level like deployment, the development process, source control, concurrent development, automation of tedious processes, development environment (OS, IDE, location of software components). And even "small" things like VS solution/project layout. SharePoint offers low level customization and high level customization (And in between), which should you use and when? What are the pros and cons for using each. If I use the high level (Using the SharePoint Designer, et al) how do I concurrently work with other developers and merge our changes (Since I will be developing locally)? How do I integrate source control? If I use the low level how can I be productive? Is there a hybrid approach that gives me the best of both? And many, many more questions (I could go on and on). "Yeah, I can do this really cool thing quickly" but there is so much more to it. In my experience, moving from WinForms or ASP.NET development to SharePoint development will require you to rethink all those high level things you already know. And unfortunately because of the immaturity of the platform and the relative lack of high level guidance it's hard to know exactly how to do things. Things that you would normally take for granted in a traditional app (Because you already have figured them out) are major considerations in SharePoint. I really hope that there is more of an influx of guidance as the platform matures, not just how to do certain technical tasks. This goes back to point #1, you will need to know the platform well first before embarking on designing and building your app so that you can make decisions on the higher level issues.

3) Learn different options without prejudice. For example I made the mistake of overlooking SharePoint designer because in a number of places I read that it was a replacement for FrontPage. That wasn't going to help me! A coworker of mine fortunately looked into it and found that, although it is a web designer like Front Page, it is tightly integrated with SharePoint and opens up the door to do some amazing customizations (Beyond just look and feel) without writing code. Again, point #1!

4) Don't reinvent the wheel. Before creating custom code, see if it can be done in SharePoint on in a "SharePoint" way. Again, SharePoint is a big shift. How you might approach a problem as a WinForms/ASP.NET developer will more than likely be different than how you would approach it in SharePoint. Often the SharePoint way will be quicker (After the learning curve of course), better, fit the SharePoint paradigm and require little or no code. This has gotten me numerous times! Point #1!!!

5) If you need to produce deliverables immediately and you don't know SharePoint you may want to just use traditional tools. As mentioned there is a pretty big learning curve, so if you decide to embark on the SharePoint route make sure that the project will allow for that learning curve. Otherwise you may be putting yourself in a stressful situation. Don't underestimate the amount of time it will take to get up to speed with SharePoint from both a technical and high level perspective.

Ok, no more rambling. Bottom line is that SharePoint is very powerful and very configurable. And I bet over time it will become a standard M$ RAD tool. There's no reason to implement all these common features from scratch when you can use a configurable, extendable platform that already offers them (Think Java, .NET Framework, RoR, etc). But go into it with knowledge as its a fundamental shift from using the classic WinForms and ASP.net approach.

I'm not going to post technical or high level guidance yet as I am still learning and figuring things out, but at some point I will definitely share that.