Hello all,

I'm putting together a control that is to be hosted within IE. I am aware of the CAS restriction running the control in the browser, so I've created a custom installer which will add the permission that I need for our signed control. The .msi installs the permissions fine with one drawback. It installs the control's assembly and adds the entry into add/remove programs.

The .Net Framework Configuration Tool provides a way to create an .msi to push-out permissions with a .msi, but that doesn't help in this scenario because it simply overwrites the permissions on the target machine with a "snapshot" of the permissions from the machine that generated .msi. Otherwise, the policy depolyment .msi generated by the Framework Configurtation tool behaves the way that I would like in the fact that it doesn't install anything and it doesn't add an entry toadd/remove programs.

I would like to have my .msi run justcustom installer without installing the control's assmebly or anything else. Is there a way to build a .msi (with Visual Studio) that runs just a custom installer class without installing the assembly?

Thanks for the help. It is appreciated!

Nathan

There's no way to call an custom action installer class in an assembly without having that assembly installed on the target system. Internally, the call on the installer class is via a C++ Dll embedded in your install, and this cranks up the .NET runtime, and needs to find your assembly to instantiate installer classes etc. Doingthis requires the assembly to be in the file system - that's the way it's implemented. If you were to just directly call a C++ Dll you could right-click it, marking it Exclude, and there's built-in support for calling C++ Dlls that aren't installed (just like the first stage of calling installer classes).

There's no way to call an custom action installer class in an assembly without having that assembly installed on the target system. Internally, the call on the installer class is via a C++ Dll embedded in your install, and this cranks up the .NET runtime, and needs to find your assembly to instantiate installer classes etc. Doingthis requires the assembly to be in the file system - that's the way it's implemented. If you were to just directly call a C++ Dll you could right-click it, marking it Exclude, and there's built-in support for calling C++ Dlls that aren't installed (just like the first stage of calling installer classes).