You can't use restricted mode to deploy a managed code (C# or VB.NET) solution in email because InfoPath doesn't allow managed code to run in restricted mode (for good reasons).

You have 2 options:

• Sign the xsn using a digital certificate
  • Pros: the future is digital certificates
  • Pros: publishURL is not removed
  • Con: it will cost you some money to buy one (if you don't already have one)
  • Con: if the publisher isn't trusted by windows you have to jump through more hoops
• Create an MSI using RegForm
  • Pros: easy to do - check it out in the InfoPath SDK
  • Pros: easy to install - no hoops to jump through
  • Cons: removes the publishURL

Q: What's the publishURL?
A: The publishURL is an attribute in the InfoPath form template's PI that describes where the form lives. It is set when you publish to a location.

Q: Why does RegForm remove it?
A: Couple reasons. One: RegForm was created in InfoPath 2003 version 1 as a means to create a URN-based solution (i.e. a solution that is based on it's name, not a location). Two: for security reasons, publishURLs need to be removed before a solution can be “installed“ on a machine. Note: installation is different thing than simply caching as it allows the solution to run Full Trust.

Q: Who cares about publishURL?
A: Ah, yes. The meat of the matter. If you want to create a single form that submits requests from outside (via e-mail) but implements workflow for inside (a corporate network) then your xml forms will have to have the publishURL so that when an internal user opens them it redirects to the internal website where the workflow happens.

Q: Why do it all in one solution?
A: Good point. You can implement the split outside request / inside workflow using two solutions but that would require hardcoding the location of the internal form library in a secondary data source, and it will be more work.