The file manifest.xml does not exist in the solution package

I do a lot of SharePoint development. I always package up my code for deployment into a SharePoint solution file (a WSP file). Every now and again, when I try to add the solution to the SharePoint farm using the command:

stsadm.exe -o addsolution -filename [solution_file_name.wsp]

I get the error:

"[solution_file_name.wsp]: The file manifest.xml does not exist in the solution package."

To make a long story short, this is often caused by a default setting in the makecab.exe utility that I use to create the WSP file. Just a bit of trivia for the young kids here, makecab.exe is a very, very old tool. It was used way back when for packing software for distribution onto floppy disks. You know, the things that were about 100 times larger than an SD card and held only 1.44 MB of data. That is in fact where the default settings on makecab.exe actually come from: the default file size for the generated CAB files (WSPs are CAB files) were designed to fit onto those old 3.5 inch floppy disks.

But, the makecab.exe utility is extremely flexible and customizable. Check out the Microsoft Cabinet SDK for more details. Here are the relevant directives to set in the DDF file in order to get rid of that out-dated file size limit:

• .Set CabinetFileCountThreshold=0
• .Set FolderFileCountThreshold=0
• .Set FolderSizeThreshold=0
• .Set MaxCabinetSize=0
• .Set MaxDiskFileCount=0
• .Set MaxDiskSize=0

Vista reports inaccurate available memory

Last year I wrote a post about how some x64 (64-bit) systems cannot use more than 3 GB RAM, even though that is one of the main purposes of getting an x64 system.

During the course of working with one such system, I discovered an unsettling development: the Vista x64 system that previously could not use more than 3 GM RAM started reporting that it could now use all 4 GB of installed RAM. Just a couple of months ago, Vista x64 reported that the system could only use 3 GB RAM.

I was confused.

The reason the system could not use all 4 GB RAM was because of a limitation in the chipset the manufacturer had used. There was no hardware change, so I did not see how the system could now address the additional memory. Yet, there it was, when I right clicked on the computer properties, Vista said that there was 4 GB RAM.

A friend of mine finally helped to crack the nut. In some BIOSes, the BIOS will actually report two different values the "memory in the system". The BIOS in this system reported correctly that there was 4 GB RAM installed, but it also reported that only 3 GB RAM were addressable. Read the previous post for the details. Before the Vista update, the System Properties screen reported the amount of addressable RAM in the system. After the update, the System Properties screen started reporting the amount of installed RAM in the system, even if a significant portion of the RAM was unusable by the operating system. You can get to the System Properties screen by right clicking on Computer in the Start Menu, and select Properties.

That's a big problem!

The whole point of the System Properties screen is to give users a fast glance at the capabilities of a particular computer. The information has to be accurate. I have often used that screen when shopping for a computer in retail stores.

So, if the System Properties screen can't be trusted, how do you figure out how much memory the system can really use? Well, my friend found a good way. Open up the command prompt and type SYSTEMINFO (Start -> Run -> Cmd -> Ok -> SYSTEMINFO). You can read more about the SYSTEMINFO command here.

Here is a comparison between the SYSTEMINFO command on the left, which correctly reports the amount of usable RAM as 3 GB, and the System Properties screen on the right, which incorrectly reports the amount of usable RAM as 4 GB:

(Click on the image to see a larger copy)

The contradictory information between the two screens is highlighted in yellow. I really hope this gets fixed soon. As more and more people start looking at x64 systems, they need an easy, reliable way to guarantee that the system that have purchased or are considering can actually use all of the memory for which they are paying.

Update to SharePoint Designer 2007 Workflow on Task Lists

This is an update to my earlier post on SharePoint Designer 2007 Workflow on Task Lists

TBone has a nice article about changing the auto-assigned workflow task. The article can be found here:
http://www.sharepointblogs.com/tbone/archive/2008/01/10/ode-to-joy-changing-the-task-list-for-auto-generated-tasks-within-sharepoint-designer.aspx

Thanks TBone!