I am supporting some classic ASP pages. One of the core 3rd party components had a leak and was fixed with a new version of their CAB. For first time users or the ones who deleted the objects, browser prompts and downloads the object. How can new cab be made available for existing users with limited privileges?
If their privileges don't include downloading/installing ActiveX, you will have to have a user with elevated permissions login and download the components. We have our support center, login to the user's computer, and login into our website. This downloads the components.
The only other option is to set up some sort of administrative deployment system, possibly packaging the objects for Windows "Run Advertised Programs" or something similar.
Related
I need to demonstrate a test version of my app. I DON'T want to load it to the store yet. I want create an installer of my app, so the user can go to my site and install the application by clicking.
First of all, have you read the documentation including developer installation, enterprise installation, publishing on the Web Store only to test accounts, and recent announcements of changes? Assuming you have, then with the exceptions listed in those sources, all apps/extensions must be published in CWS. They don't have to be listed publicly, but they do have to be published there.
Your best bet is to use the test-account feature of CWS for your demonstration.
This is very easy, yo can create the installer vía chrome://extensions > Developer Mode > Package extension.
Then you got the .crx file, you can upload it anywhere and share it. To install it, user must open chrome//extensions and drop the file in the page.
The option to install from webpage by clicking was disabled in Chrome for security reasons.
We have a legacy AutoCAD plugin for integration with our applicaton.
The plugin uses ARX and an acad.lsp file to load itself on startup. The plugin installer adds the plugin directory to the ACAD support path in the registry under HKCU...\General\ACAD.
The problem with this approach is that modifying the support path under HKCU only affects the current user. Iterating over all profiles and adding the support path to each of them seems to be a bad approach as pointed out in Raymond Chen's Beware of roaming user profiles. This also leaves out new users, whose profiles have not yet been created on the machine at the time of installation.
Therefore I'm looking for a way to register an AutoCAD plugin for all users upon installation, be it a global support path or some other way of registration.
The plugin should work on AutoCAD 2006 through 2012.
Read this http://through-the-interface.typepad.com/through_the_interface/2006/09/automatic_loadi.html
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.
I've developed a WPF application. A large company is trying to make my application available to users' desktops. The traditional way to do this would be to point the users' browsers to:
http://www.MySite.com/MyApp.application
But the I.T. group at this company has configured their proxy server in such a way so as to block .application files for security reasons. They do, however, allow .exe files to pass through their proxy server and execute on client workstations. The irony of allowing .exe's from the Internet while blocking .application text files "for security reasons" isn't wasted on me but let's put that aside for a moment.
What kind of workaround would you recommend that would allow my app to launch from client desktops given that .EXEs are allowed? My first thought is to write a mini launcher app that does nothing more than download a .zip'd version of the .application file and all dependencies to a temp folder on the user's machine and then launch the .application file from there. Is there a better solution?
FWIW: Google has figured out a way to deploy their Chrome browser to Windows desktops in corporations like this one, despite the fact that ClickOnce is their deployment mechanism. If you view the source code at:
http://www.google.com/chrome/thankyou.html?&oneclickinstalled=
...you'll see they're pointing to an installer at:
/update2/installers/clickonce/GoogleInstaller_en.application.
That's a clickonce file. But somehow they've figured out a way to wrap it in an .exe in order to bypass proxy restrictions on .application files. I not familiar enough with JScript to understand what they're doing but it works. I'm trying to emulate this behavior for my own app.
This may not work for your situation. However, one possibility is to xcopy your exe and any dependencies to a folder on your webserver. Add a link in a webpage to your exe so your users can launch the app by clicking the link. In order for any of the users to be able to run the exe the first time, a caspol script needs to be run on each user machine to allow your app to run. Whenever you update the app, just xcopy the new version to the same folder on the webserver.
Does full trust mean the same as Run As Administrator? I have read things stating that "for this to work, the application must be a full-trust application." Is that the same as you must have administrator privileges to run the application? If not, what's the difference? How can you tell if an app is "full-trust"?
I am told that "Administrator or not, .Net apps won't do certain things if they aren't running from a 'trusted' location." What is a "trusted location"? If you run an app from a "trusted location", can you do things that "require full-trust" without being an administrator?
No. Full-trust is a .NET term used to indicate that it's not running in a reduced-priviledge .NET sandbox. In .NET prior to 3.5 SP1, this included running from a network share (in the default configuration). It also includes running as a ClickOnce application that has not requested additional permissions, or in some other browser-based sandbox.
Full-trust means it can do anything the user it is running as can do, not that is running as an administrator.
No. As of version 2.0, the .Net framework has it's own little filesystem setup for security. Administrator or not, .Net apps won't do certain things if they aren't running from a 'trusted' location.
Just about anything on your local hard drive is trusted, but (and supposedly they fixed this for 3.5sp1) even the local intranet is not trusted, so most .Net desktop apps will fail to even start if they're sitting on a network drive or share.
You can change the configuration on a machine so it will allow apps from that zone, but it has to be done for every machine that's going to run the application, which breaks a common corporate deployment scenario.
From an ASP.Net standpoint, it also means that certain activities require more 'trust' than others. Sending e-mail, for example, can cause exceptions if not set up correctly.
Basically Full Trust means that the C# code has total control over the current (.Net) process and all processes running under the Application Pool account.
It is the same as running a C++ dll
Admin access will depend on the IIS settings (ie. if you run the website under System or an admin account)