Wrong content type when selecting "New Item" using content types: Continued

Aha! more progress on this one. I've narrowed it down now - this issue only occurs when you use Office 2007 documents that have already been stored in SharePoint 2007 as your template for a content type. This includes documents that were in SharePoint and now are not, or documents currently stored in a library.

If you create your templates from files using good ol' fashioned pre-SharePoint storage (hard disk ;) ) and upload them using the "upload a new document template" option along with the content type, then you will get the desired results.



Hmm, I'm waiting for Microsoft to try and convince me now that this is a "know issue by design". It's a clear bug. Once SharePoint has added a customxml folder and associated files into the docx package you're pretty much screwed. This also puts the end to any ideas of using a standards library as the basis for all the content types used within the business. Also - try getting your quickparts spot on if you can't ever put the template in the library to get the quickparts list populated...

The workaround suggested elsewhere - upload documents only, don't create from new - is pretty lame I think. Let's see what Microsoft have to say...

Code Signing for Click Once - The Free Way

When writing click once applications deployed over the web you are going to need to sign your manifest files with a certificate. In development you can quite happily test this by using the "create test certificate" option and use a certificate signed by yourself.

It's not ideal though - particularly if more than one person is developing and deploying the product - as each person ends up with their own certificate. Deploying to test becomes a chore as you have to uninstall from the test device each time to avoid manifest errors.

This issue can be compounded when you have components in the "partially trusted caller" category, such as infopath forms running inside the windows InfoPath form control. Each of these forms can also be signed with test certificates - the end result being anyone who makes a change to the form will be told that the certificate is invalid, resign it with their own, and have further fun deploying to test.

The answer is to make a common certificate for code signing - using the makecert.exe tool. For example:

C:\Program Files\Microsoft Visual Studio 8\VC>makecert -r -pe -n "CN=Temp Code Signing" -b 01/01/2005 -e 01/01/2100 -sky exchange -ss my

creates a pub/priv key signed certificate in the "my" section of your certificate store. You can export this using the cerificate store mmc snap-in, and use the "select from file" option to add the certificate into your project.

Now it is a project file, the certificate isn't called "P_Devenney" or some rubbish, and you can sign your infopath forms from it too. Each developer can sign with the same certificate, saving a load of test deployment hassle, and simulating a live scenario far better.

You can actually use this in a live environment too - if you accept it's disadvantage of being highlighted to the user as an unverifiable certificate. It does have an advantage over commercial code signing certifcates too - you'll see my cert was set to expire in 2100! Unfortunately most providers resign each renewed code signing certificate with a different private key - meaning that the end user has no choice but to uninstall and reinstall - having received scary warnings that the manifest is not from the same publisher! We actually use the makecert certificate in some intranet enviroments, as trusting the certificate once on each device is no real hassle.

Selecting Content Types from the "New" menu gets the wrong content type

The scenario

• Create 2 breand new content types/ Provide each one with a word 2007 document as the template (each with some different text to test success).
• Attach both content types to a document library.
• From the "new" dropdown on the doc library select the last content type on the list.
• Add some text add save back. The content type attributed to the document will be the first one in the list (the default) *even though* we selected the correct type.
• saving to disk and inspecting "item4.xml" inside the docx shows the wrongly selected content type. Correct the documents content type in sharepoint, download to disk and inspect item4.xml and you will see the correct content type.
  

This is a bit of a weird one. I'm going to do a bit of investigation and report back through my blog. It's rather frustrating when you have a different workflow that kicks off on the creation of a document of each content type

The B2B upgrader timer job failed

I found a great article on getting WSS 3.0 SP1 working after receiving the worrying "The B2B upgrader timer job failed" error message. I'm only linking it here in order to try and bump it up good so others can benefit.