We use a VSTO based Word template to make sure all our documents have the same styling and are suitably reformatted for shipping to clients e.g revision comments removed, contents pages up to date etc. Normally we will create a new document using this template from our SharePoint server and all is OK. However sometimes you are on the road when you started a document so you just create it locally using a locally installed copy of the template. In the past this has not caused me problems. I have my local ‘My documents’ set in Word as a trusted location and it just works fine.
However, of late due to some SSD problems, I have taken to using the SkyDrive desktop application. So I now save to C:\Users\[username]\SkyDrive and this syncs up to my SkyDrive space whenever it gets a chance. It has certainly saved me a few times already (see older posts my my SSD failure adventures)
However, the problem is that I can create a new document OK, VSTO runs, and save it to my local SkyDrive folder, but then I come back to open it for editing I get the error
The problem is my SkyDrive folder is not in my trusted locations list (Word > options > trust center > trust center settings (button lower right) > Trust locations)
So I tried adding C:\Users\[username]\SkyDrive – it did not work.
I then noticed that when I load or save from SkyDrive dialogs say it is coping to ‘https://d.docs.live.net/[an unique id]’. So I entered https://d.docs.live.net (and its sub folders) as a trusted location and it worked.
Now I don’t really want to trust the whole of SkyDrive, so needed to find my SkyDrive ID. Now I am sure there is a easy way to do this but I don’t know it.
The solution I used was to
- Go to the browser version of SkyDrive.
- Pick a file
- Use the menu option ‘Embed’ to generate the HTML to embed the file
- From this URL extracted the CID
- Added this to the base URL so you get https://d.docs.live.net/12345678/
- Add this new URL to the trusted locations (with sub folders) and my VSTO application works
Simple wasn’t it.
I downloaded and installed the Office 2010 technical preview today. All seemed to go OK (after I realised I could only do an in place upgrade from 32bit Office 2007 –> 32bit Office 2010), once the upgrade was done I could load Word and using our VSTO based document templates all seemed to work fine. However when I tried Outlook I got a problem.
On the first loading it took a while, telling me it was doing something to 40K+ items, presumably checking the local OST file, but then seemed to load OK. However after about 30 seconds it crashed, and continued to do this every time I rebooted Outlook even when I was tried safe mode, add-ins switched off and/or offline working. It all had no effect. Checking the event log I saw I had the error:
Faulting application name: OUTLOOK.EXE, version: 14.0.4006.1110, time stamp: 0x4a468538
Faulting module name: mlang.dll, version: 6.1.7100.0, time stamp: 0x49eea59f
Exception code: 0xc0000005
Fault offset: 0x00016aef
Faulting process id: 0x1060
Faulting application start time: 0x01ca06e3140fb30d
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE
Faulting module path: C:\Windows\system32\mlang.dll
Report Id: 5af5a171-72d6-11de-97df-001636a51764
I noticed that the in place upgrade had not removed Office 2007, so I did this via the control panel. After this Outlook loaded and was stable other than the fact the view panel would not load (was grey’d out on the menu), so stable but useless
I then tried a removing Office 2010 (there is no repair option) and reinstalling again using the same 32bit media. This time it knew it was not doing an upgrade but a new install. Once this completed I loaded Outlook and it worked fine including picking up my existing OST file (from a non default location, I keep it on a bitlocker partition) and also still had my CRM 4.0 add-in configured and working.
So it seems the upgrade can get bit confused
I have been getting the error "The required version of the .NET Framework is not installed on this computer." (event id 4096 in Event log) when trying to install a VSTO application from both a ClickOnce deployment and a local copy. This is interesting as the .NET framework is installed (on my 64bit Windows 7 PC) and the VSTO application was developed on the self same machine (and works in Visual Studio 2008).
The fix, it turned out, was to uninstall Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0 Runtime) (x86) and then reinstall it, once this was done the install worked fine.
When you are using a VSTO enabled Word Template inside a SharePoint custom content type you have to be careful which actual .DOTX file you use within the SharePoint custom content type.
- DO NOT – use the .DOTX from your VSTO Visual Studio project directory
- DO USE – the .DOTX from the the project's ClickOnce publish location.
The key point here is that until you have published the VSTO project via ClickOnce the .DOTX template does not know where to find the deployment of the associated assemblies. The copy in the project directory never actually knows this location as it is just a source file not a deliverable.