using in sharepoint

May 14, 2009 at 7:24 AM
Edited May 14, 2009 at 8:10 AM

hi robertk,

thank for your work, it's very very interesting.

I try to use flexdoc in sharepoint, making a solution for trasform data from infopath form and make a work document based from template docx.

I found only one big sharepoint security problem.

I suggest you to modify you code for avoid it.

you have to move in a class the script and change mergedata function, for example:

            xsltArgs.AddParam("culture", string.Empty, Thread.CurrentThread.CurrentCulture.Name); // Get from arg
            transform.Transform(template, xsltArgs, outputStream);

change in

            xsltArgs.AddParam("culture", string.Empty, Thread.CurrentThread.CurrentCulture.Name); // Get from arg
            FlexDoc.FlexDocTransformer obj = new FlexDoc.FlexDocTransformer();
            xsltArgs.AddExtensionObject("urn:pdc:infosupport-xslt-dyn", obj);

            transform.Transform(template, xsltArgs, outputStream);

in the FlexDocTransformer class you can copy all source script and delete it from xlst.

best regard


May 15, 2009 at 6:27 AM

Hello FabioA,

Nice to hear about someone using it AND how it's being used! I think FlexDoc should be a perfect fit for your scenario.

What is the exact exception you get? Does it help when you add the FlexDoc.Api.dll in the GAC? Maybe the way you deployed it ((doclib eventhandler/workflow?) into SharePoint didn't give if the right code-access security? And are you sure that using the FlexDocTransformer-assembly DOES get enough trust? (I don't have a SharePoint environment at hand, so I can't test it myself)

The reason for me not to separate the script (C#) code from the xslt is that the xslt can be easily tested from any environment, not just Visual Studio. I personally prefer XmlSpy. But if you can't get it to work, I will move the code to a separate assembly, especially because the SharePoint-platform is a very good candidate for using FlexDoc and should therefore be well supported.


May 16, 2009 at 11:58 AM

Hello Robert,

the exception is the same showed at this link:

I got your source code and copied it in my signed assembly. I made a simple class for setting repository parameters (source docx, infopath form for data, namespace, ecc.) and to interface your classes.

I tried to execute the code into an internal codeblock inside the RunWithElevatePrivilege.

I tried also to modify web.config PageParserPaths's section adding the page that execute code, but only applying modify written above I solved exception.

Sharepoint  avoids execute not signed code and the script in xlts file is compiled just in time, but non signed.

I made some little changes in your code to execute it using a docx files with tags without xpath (in some scenario's I need it), inserting

            if (expression=="") return context or return "" in Select and Evaluate functions.

 Moreover, I'm not sure that the <xsl:template name="RenderDataItem"> is correct, in some cases I think it is necessary to generate

                <xsl:element name="p" namespace="">

 Isn't it so?

Best regards




May 18, 2009 at 7:11 AM

Hello Fabio,

I will add a workitem about moving all script code to a separate (signed) assembly to prevent any security issues like the one you encountered.

Can you explain why you use tags without an xpath-expression specified? If you're just using them as markers, you should use your own xml-schema. You could also use empty content controls as markers: you can manipulate those from the Open XML SDK DOM, instead of needing to edit the xml.

Can you supply me a template where FlexDoc doesn't render the paragraph (p) tag? I want to know in what situations Word adds the xquery-tags without embracing them inside a paragraph.



Sep 10, 2009 at 1:49 PM


You may be intrested in solution we just released. SharePoint Document Generator is ready to use solution for sharepoint at .



Sep 18, 2009 at 7:27 AM
FabioA wrote:

 Moreover, I'm not sure that the <xsl:template name="RenderDataItem"> is correct, in some cases I think it is necessary to generate

                <xsl:element name="p" namespace="">

 The latest sources fix the issues with the missing paragraphs. Check it out.