Re: Scan and Upload v16 .NET with Caspol.exe deployment

NOTE:
1. THIS IS A VERY ADVANCED DEMO. You should be familiar with .NET UserControls, Web applications, and ActiveX control web deployment (CAB files). Please carefully read the instructions that come with the demo.
2. There are some limitations to this kind of deployment, so it's not the recommended type. For more information on those limitations and an example that works around it, please see the 3rd post in this thread.

This demo shows how to scan on the client side and then upload the images onto the server using ASP.NET with the LEADTOOLS v15 .NET libraries.

Edited by moderator Friday, August 9, 2019 8:42:07 AM(UTC)  | Reason: Not specified

This is the same ScanUpload demo but uses a simpler deployment method.  It just uses standard .NET deployment and relies on your .NET framework configuration settings like the basic Winforms UserControl project (http://support.leadtools.com/SupportPortal/CS/forums/7653/ShowPost.aspx).

NOTE: THIS IS A VERY ADVANCED
DEMO.  You should be familiar with .NET UserControls, Web applications,
and ActiveX control web deployment (CAB files).  Please carefully read the instructions that come with the demo.

This is the same basic application as both projects above, but uses 16.5 and shows how to update the control that's deployed via COM/CAB.
 
The problem with CAB deployment of ComVisible .NET UserControls is that they don't get registered by IE.  Therefore you must install the files, add them to the GAC, and then register your control with RegAsm.exe (this is what the original COM/CAB deployment project above did).  This works great for the initial install, but RegAsm.exe doesn't register .NET assemblies the same way that regsvr32.exe registers standard ActiveX controls and causes versioning problems because RegAsm always uses the framework version as the assembly version.  Basically, if you make an update to the control and update the CAB file and increment the version numbers, IE won't redownload and update the control!
 
The workaround for this is to add a registry key that IE looks at which RegAsm doesn't add: HKEY_CLASSES_ROOT\CLSID\{[CONTROL GUID]}\InstalledVersion with the default value set to your cab file's version in the tag.  I have updated the CAB file and installation package to resolve this.
 
When you need to make an update, you must do two things:
1. Update the cab file version in the tag.
2. Update the registry key value to match the new cab version in the setup project.  To get to the registry keys in your setup project, right-click on ScanUploadSetup in the solution explorer, then select View -> Registry

This is the same basic application as the projects above, but uses 16.5 and shows how to use Caspol.exe to deploy the application

This is the most highly recommended style of deployment because it is safe, relatively simple, and easier to maintain and update.

Edited by moderator Friday, August 9, 2019 8:46:22 AM(UTC)  | Reason: Not specified

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.     

I've updated this project to use LEADTOOLS v17.5 DLLs with VS 2008.