This has nothing to do with Smart Documents, but I just wanted to mention Sig Weber's XSLT files that enable you to easily show RSS feeds as web parts on a Sharepoint site, without even having to install anything.
You simply add a built-in XML Web Part, point it at the RSS feed, and add one of the three XSLT files as the XSL source (each is a different display style).
Simple, easy and fun for the entire family.
http://playground.doesntexist.org/
Technically, the same smart document can apply to both Word and Excel. In practice, if you want your smart-doc to actually DO something, chance are half your code will be hacked and kludged to work for both. For example:
- The XML model is different for the two applications.
- To get Smart Document controls to respond to the entire document in Word, you'll use the element <My schema namespace>#actionPertainsToEntireSchema.
In Excel, you'll bind to http://schemas.microsoft.com/office/smartdocuments/2003#default.
Needless to say, this is not documented anywhere.
- Assuming we've accepted the fact that an ActiveX control bound to one of these generic elements in entirely inaccessible from code (Here, about 80% of the way down. Running a search for “pertains“ should do it), we still can't use the same code for Word and Excel even for standard elements: XML elements in word are of type Microsoft.Office.Interop.Word.XMLNode. Excel's XML model is different, and uses element-mapping to cells or ranges. Even if we do get a node, to get the Smart Tag Action from it we'll use Microsoft.Office.Interop.Word.SmartTag, while Excel has Microsoft.Office.Interop.Excel.SmartTag. Similar? Very. Compatible? Not necessarily.
In short - if you gotta support both Word and Excel, I would suggest having two different Smart Document solutions. It would seem like the less elegant solution, but when you start seeing every function broken up into huge, distinct if/else blocks, you can tell that something's just not right.
A few tips to keep in mind when developing and debugging a Smart Document using C# (and probably VB.NET too).
(For my own selfish ease-of-use, I will refer to Word exclusively here. All these steps should apply to Excel equally).
- When building the Smart Doc's Manifest.xml, make sure to include the <runFromServer/> tag for both the solution DLL and the schema.. This makes sure Word doesn't copy the DLL and such to the current user's profile, and thus uses the same DLL that Visual Studio is debugging.
- Create an empty document and attach it to the schema and the expansion pack. Then save it somewhere.
- In the Project Properties -> Configuration Properties -> Debugging -> Start Action, set Winword.exe as your default application to run when debugging. Pass the name and path of the document from section #2 in the Command Line Arguments field. That way we always launch Word when debugging, and don't have to mess with attaching to process and so on.
- In the Post Build Event for the project, add the following line:
C:\Windows\Microsoft.NET\Framework\v1.1.4322\gacutil.exe /cdl
(You might need to replace C:\Windows with C:\WINNT for Windows 2000. Also replace with the version of the framework you're using).
This command clears the Download Cache. If we don't run it, Word will use an older, cached copy of the DLL.
Note: If Word is running, this command will fail. Don't forget to close Word.
- Once we're in Word and debugging and all, it's best to manually close the document rather than just brutally stopping the debugging session. Otherwise we'll get all those “Word recovered your document from the sudden crash, do you want to restore it?“ questions and taskpanes and all popping up. Best to spare yourself the aggravation and close it politely yourself.
Those should get us started. Now to fight with ActiveX controls...
Smart Document Deployment is definitely an issue that needs a lot of work.
For the past week I've been repeatedly stumped in the simple task of loading a Smart Document solution into Word. Not a specific, possibly-buggy SmartDoc - ANY SmartDoc solution. Even ones that worked before. Even the SDK-supplied SimpleSample. ALL.
I followed the MSDN instructions quite specifically. (Here).
I tried to debug using all the information here.
I added Code Access Security.
I changed namespace names.
I tried read the Fusion log to see what's going on.
I uninstalled and reinstalled Office 2003 TWICE, in two different languages.
And all this time this nagging, teasing, whining headache of an error message popping up. “Missing or invalid Smart Document”. Grrr... I'll show him missing or invalid!
Hmpf. Well. As always, the answer came from a totally unexpected direction.
Well, a rather expected direction, but in an unexpected manner. The Troubleshooting document listed above mentions the following possible cause:
You have Microsoft Windows® .NET Framework 1.0 and Microsoft Windows® .NET Framework 1.1 installed on your computer. However, you accidentally configured the code access security policy using version 1.0 of the .NET Framework instead of 1.1. Correct this by using the .NET Framework 1.1 to grant Full Trust permissions to the assemblies. Remember to delete the previous settings.
I have never had 1.0 installed on this machine, so I didn't suspect a thing - but then I remembered that I *DID* install the 2.0 framework a couple of weeks ago, trying to get Whidbey to run here. (Unsuccessfully, I might add). Even though I built my SmartDoc project in Everett linked to Framework1.1, and I set my code-access permissions in the Configuration tool for Framework1.1, and everything was supposed to be side-by-side and fine and dandy - and nevertheless, once I uninstalled the 2.0 framework things started working immediately.
My guess is Word tried to load the managed Smart Document DLL using the 2.0 DLLs. Does this make sense? Is there any reason this happens? Any way to stop it? Do I need to specify explicit binding rules in WINWORD.EXE.config to get it to bind properly when both 1.1 and 2.0 are installed?