The only supported way of deploying our runtimes is to use one of our prepackaged msi's.
We do not have any documentation for manual deployment or anything that lists what specific dlls, registry settings, etc are needed to run specific configurations (ie web app vs windows apps).
As well as what Jason posted CR MUST have local PC Admin rights because we need to get past DEP/UAC etc. as well as be able to register the COM components, insert all of the registry keys required and the usual folder creation and file copying. Without it CR simply won't install properly and your app will never run. As noted in those other posts if you write a .NET app you have no choice but to use/set the native permissions and file distribution. If it's a WEB based app the you deploy it on each WEB server, users get a Viewer and Printer control through a browser download. But for Windows, it's a must.
IT departments have the ability to push out Special permissions for users to install software, not a CR configuration so check with your IT group or Microsoft and search on Profiles. So the each users doesn't need to be granted Admin rights to use it but they need it to install, assuming when installed it's set for All users. Other option is a local network Admin install on each PC. Not the nice way of doing things though.
Bottom line is because it's a Native .NET windows app you have no choice but to distribute all of CR's runtime and dependencies.
Hi Don, thanks, your response was very helpful. I was really hoping that there was a way to deploy a "thin" version of CR via just including some dlls, but obviously that isn't the case.
That's a bit frustrating, but we have an acceptable workaround, we will log which machines are running the app and I've written a script which can silently install the runtime. Have tested it and it works fine.
You're correct about the ability to push changes, in an ideal world I would push this out as a group policy against the OU which contains the application groups, however our service provider is incompetent so it's more efficient to just do it ourselves without group policies.
It's a real shame the CR still uses COM after all these years. Time for a rewrite!
Great work around... You obviously know what you are doing...
As for COM, yes we know... when MS announced they were dropping COM for .NET we had to change but because COM was so prevalent in our source we had no choice but to write wrappers, then due to pressure from the DEV community MS had to supported COM again but by that time we could not revert back so goes life....
We are trying to reduce the size of our distribution as much as possible, it is a common request...
You could always move to Java....