locked
Deploy InfoPath code behind dll with WSP RRS feed

  • Question

  • I have a state machine workflow with two custom task forms, each with code behind. I can get everything deployed and working fine with the exception of the code behind dlls. Those I have to manually place in the feature folder that is created for my workflow. What's the best way to deploy these dlls with the wsp file and get them to go into the feature folder (as opposed to the bin folder of the GAC)?

    I have the forms included in a module that I placed inside the workflow folder. So I have two elements.xml files and two items in my feature, the module and the workflow.

     

    Monday, April 25, 2011 8:52 PM

Answers

  • I had to remove the dll block from the app for deploying and add the dll listing back on after the deployment.

    It does not affect the workings of the form. But during deployment mode I think you need to remove the block on dlls.

     

    Tuesday, April 26, 2011 5:55 PM
  • Sorry, I mistakenly alluded that you can change the path to another location entirely. What I should have said instead is that you can redirect it to a subfolder in either the GAC or a webapp folder by entering the path in the Location box.  AFAIK, you can only deploy the external DLLs to those locations.  Is there any particular reason you don't want to deploy the DLL there?


    - Kemp Brown [MSFT]
    Wednesday, April 27, 2011 2:06 AM
  • The only options for deploying .dll's to a SharePoint environment are going to be:

    1) Trusted / Farm Solutions - deploy to the GAC or the Web App bin.  You can specify subfolders as Kemp states

    2) Sandboxed Solutions - deploy to local storage cache on servers running User Code service - at C:\ProgramData\Microsoft\SharePoint\UCCache.

    For Sandboxed solutions your State Machine workflow isn't supported, so you are stuck with option #1.

     

     

     

    Wednesday, April 27, 2011 5:17 AM

All replies

  • One way to include an assembly in your project is to use the Package Designer's Advanced tab to specify an assembly, either an existing one or from the project's output.  You can specify the assembly to go to the GAC, web app folder, or other location. Here's a screenshot of it: http://blog.sharepointdevelopment.nl/post/Add-an-assembly-to-your-Visual-Studio-2010-SharePoint-Package.aspx and here's a how-to from MSDN: How to: Add and Remove Additional Assemblies.

    HTH,


    - Kemp Brown [MSFT]
    Monday, April 25, 2011 10:41 PM
  • So how do you specify a location other than the GAC or bin folder? I didn't see anything that said you could deploy to a third location. The only deployment target options are the GAC and WebApp. The XML uses the DeploymentTarget attribute, which has only two values. Am I just completely missing something?
    Monday, April 25, 2011 11:33 PM
  • Add a module to your project. Copy all the IP forms and its dlls. The Module element file will be automatically updated with the files. This way the ip forms and dlls are deployed to your feature folder.

    Refer to this article. I have deployed IP forms with Managed code this way

    http://www.stuartroberts.net/index.php/2010/11/30/deploying-infopath-form-sharepoint/

     

    HTH

    Tuesday, April 26, 2011 12:38 AM
  • That blog describes how to deploy the forms, which I have had no trouble doing. It even says that they won't be dealing with code behind. My problem is with the dlls and the dlls only.  I did try including the dlls in the module, but when I place the dlls in the module, the feature will not deploy because it contains items blocked by the SharePoint farm. I would imagine that the best solution is not unblocking that as that seems like it would be a huge security hole.
    Tuesday, April 26, 2011 5:47 PM
  • I had to remove the dll block from the app for deploying and add the dll listing back on after the deployment.

    It does not affect the workings of the form. But during deployment mode I think you need to remove the block on dlls.

     

    Tuesday, April 26, 2011 5:55 PM
  • Sorry, I mistakenly alluded that you can change the path to another location entirely. What I should have said instead is that you can redirect it to a subfolder in either the GAC or a webapp folder by entering the path in the Location box.  AFAIK, you can only deploy the external DLLs to those locations.  Is there any particular reason you don't want to deploy the DLL there?


    - Kemp Brown [MSFT]
    Wednesday, April 27, 2011 2:06 AM
  • The only options for deploying .dll's to a SharePoint environment are going to be:

    1) Trusted / Farm Solutions - deploy to the GAC or the Web App bin.  You can specify subfolders as Kemp states

    2) Sandboxed Solutions - deploy to local storage cache on servers running User Code service - at C:\ProgramData\Microsoft\SharePoint\UCCache.

    For Sandboxed solutions your State Machine workflow isn't supported, so you are stuck with option #1.

     

     

     

    Wednesday, April 27, 2011 5:17 AM
  • Ah ok, putting something in the location text field makes sense. The dlls need to be deployed there because the forms don't function otherwise. From what I've tried and found through research the forms only look in their local folder for the dlls. So from the location text box could I navigate up out of the virtual directories folders back to the system drive and then to the 14 hive folder? Something like ..\..\..\..\..\..\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\<my feature>\Forms\<name>.dll. 

    Just tried the above, and it does not let you navigate up. Looks like I'll have to stick with manual deployment for these dlls.

    Wednesday, April 27, 2011 5:32 PM
  • Wrote a script for prod deployment. basically after feature deployment copy all the dlls.

    I know it is little strange in infopath world.

    Wednesday, April 27, 2011 6:03 PM