P
Patrick Halstead
There are two main ways to deploy managed code solutions. This post
discusses some pros and cons of each.
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:
a.. Sign the xsn using a digital certificate
a.. Pros: the future is digital certificates
b.. Pros: publishURL is not removed
c.. Con: it will cost you some money to buy one (if you don't already
have one)
d.. Con: if the publisher isn't trusted by windows you have to jump
through more hoops
b.. Create an MSI using RegForm
a.. Pros: easy to do - check it out in the InfoPath SDK
b.. Pros: easy to install - no hoops to jump through
c.. 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.
Patrick Halstead
InfoPath MVP
http://www.infopathdev.com/
discusses some pros and cons of each.
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:
a.. Sign the xsn using a digital certificate
a.. Pros: the future is digital certificates
b.. Pros: publishURL is not removed
c.. Con: it will cost you some money to buy one (if you don't already
have one)
d.. Con: if the publisher isn't trusted by windows you have to jump
through more hoops
b.. Create an MSI using RegForm
a.. Pros: easy to do - check it out in the InfoPath SDK
b.. Pros: easy to install - no hoops to jump through
c.. 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.
Patrick Halstead
InfoPath MVP
http://www.infopathdev.com/