HOW TO: Deploy a .NET UserControl Using Caspol.exe

This is pretty much the same basic project as http://support.leadtools...orums/7653/ShowPost.aspx but uses a more advanced style of deployment.

For this deployment method, a welcome page is used with a dummy tag embedded.  This object tag will have the user download a CAB file which runs a batch file that uses Caspol.exe to add a URL code group to the .NET 2.0 Configuration.  

The advantage over the simple deployment is that it's done automatically and doesn't require manual modification of the .NET 2.0 configuration.  Even more important is that you only need the .NET framework and not the .NET SDK which was a common complaint of the simple deployment (the Configuration utility only comes in the SDK).

This is also better than the advanced deployment style of making the control ComVisible and registering it with RegAsm (http://support.leadtools.com/SupportPortal/CS/forums/18320/ShowPost.aspx) because it's more simple and less hassle when you update the control.  Updates will be downloaded automatically when the .NET framework detects a new version of the control's assembly rather than the webmaster incrementing the version of the cab file, installer, etc.

Keep in mind that this is a very simplistic way of doing this and is designed to show a concept and help you get started.  You should create a tool that checks for existing permissions and catches/reports errors.

IMPORTANT INFORMATION

-  Make sure you create your own GUID.  The GUID we have in the project is just a simple GUID that shouldn't be used in production environments.
-  There are 2 versions for the caspol.exe.  One is for x86 and the other is for x64.  The x64 version resides in the Framework64 folder.  The attached project handles both cases in the SetPermissions.bat file.  The project was updated for this reason.  Before it only worked on 32bit machines.
-  In the SetPermissions.bat file be sure to change the URL and the name of the security policy.  Currently we have the URL as "http://localhost/*" and the security policy name as LEAD_TEST32 or LEAD_TEST64.  This should be changed to fit your needs.

Attached is this project updated to version 17 using Visual Studio 2008.

Note: As of .NET 4.0 Framework the IEHost.dll will no longer be supported.  What does this mean?
The samples from this forum post will only work in the Framework 3.5 SP1 and earlier.

So far the only documentation we have found from Microsoft on this can found at this link:
http://social.msdn.microsoft.com/Forums/en-US/clr/thread/e293ed8e-be48-4c4a-838b-dcf3c2cec5b7

Below is an excerpt from this post:

IEHost.dll is the runtime host that provides the ability to host Windows Forms controls and run executables in IE. IEHost is a .Net 1.1 technology that provided a better model than ActiveX to host controls within the browser since they were lightweight and the controls operated under the .NET security model, where they operated inside a sandbox.

For Dev10, the proposal is to remove IEHost.dll for the following reasons
1)    IEHost/HREF-EXEs are surface area exposed to the Internet. This poses a high security risk (we already have bugs filed related to this), and most customers (by far) who install the Framework are getting very little value for this security risk. If IEHost and IEExec is left as-is, a new model needs to be designed where either (a) using this technology is safe and is always on, or (b) is as secure as today and can be configured to be turned off. The cost of doing this is very high.
2)    Customers who want IEHost/HREF-EXE-sytle controls or apps have numerous other technologies they can use, like ClickOnce, XBAP, Silverlight.
3)    Customers who want the exact same functionality as 3.5 SP1 for this feature can continue to use 3.5 SP1. This change, of removing IEHost takes effect only in .Net Framework 4.0.
4)    The opportunity cost and risk of continuing to support this feature for the CLR team is high. Going forward, we will be able to deliver more features and bug fixes that benefit more of our customers if we can remove this from NetFx4.