Closed Bug 476661 Opened 17 years ago Closed 16 years ago

KB article: How to remove the Microsoft .NET Framework Assistant Add-on

Categories

(support.mozilla.org :: Knowledge Base Articles, task)

task
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cilias, Assigned: bbayles)

References

()

Details

So, do we want to put registry editing instructions in the KB? * In a couple articles (Using the Java plugin with Firefox, Use Internet Explorer messages upon Firefox startup, No programs can load websites) we link off-site to registry editing guides. * In ((The protocol is not associated with any program)) we explain how to make a .reg file and add it to the registry. Those articles are separate issues, and should maybe be discussed in the Contributors forum... For this one, I think we should do: * Click Start, select Run... * Enter the following command: REG DELETE "HKLM\SOFTWARE\Mozilla\Firefox\extensions\{20a82645-c095-46ed-80e3-08825760534b}" Which will prompt the user to delete the key.
Sure. That looks small, so let's add this to <https://support.mozilla.com/kb/Cannot+uninstall+an+add-on>.
OK, I edited ((Cannot uninstall an add-on)). The staging copy is in this bug's URL field now. As a bonus, I also put up instructions on how to remove Sun's Java Quick Starter extension - actually, they're the same instructions, but it's a different registry key\value. We need some additional information before publishing these, though: * On Vista, do you have to be logged in as Administrator to do the reg DELETE command? I don't have a Vista machine here to check. * Does the Java Quick Starter extension get installed on Vista? It does on XP with the last few versions of Sun's Java Runtime. It didn't on my girlfriend's Vista laptop, though. * Should we merge the two sets of instructions, and then just have a list of key\values for other uninstallable extensions?
Assignee: nobody → bbayles
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I've got several problems here. First of all, we don't tell people about about:config options but we'll tell them how to poke around the registry? Secondly, these aren't our products and while they might frustrate users, they came with someone else's product. They should be sent to that product's support to learn how to customize these features, or remove that product altogether. We won't be able to follow up support if making these changes breaks something in the registry or in the original program. I couldn't find any reference to framework assistant at support.microsoft.com though maybe I'm looking in the wrong place. IMO we should be telling people that it's a component of a microsoft product, list the possible products (or is it just one?) and use our partner connections where possible to get those companies to host documents that we can link to. Java has these instructions - http://www.java.com/en/download/help/quickstarter.xml does this not remove the add-on?
ccing djst for his input, please feel free to move this discussion out of the bug if appropriate
Actually, I could see just saying "These extensions can't be uninstalled easily. Just disable them." I started a thread in the Contributors forum about what to do about the registry, if we want to continue there.
The discussion continues here: http://support.mozilla.com/tiki-view_forum_thread.php?forumId=3&comments_parentId=270707 I've changed the draft instructions in the bug URL to avoid registry editing in the meantime.
I suggest that you don't add instructions for removing individual extensions that are added via the Windows Registry. As time goes on and based on the growing popularity of Firefox, I suspect you will be seeing more and more of these types of add-ons. It's a recognized method of adding extensions to Firefox and, according to http://developer.mozilla.org/en/docs/Adding_Extensions_using_the_Windows_Registry "This mechanism is designed to make it easier for third-party installers to register extensions with Firefox and Thunderbird." Specific instructions for removing add-ons installed by third-party software should come from the software provider. The following is copied from http://kb.mozillazine.org/Uninstalling_add-ons#Windows_Registry_extension (the bracketed numbers are references) "Java Control Panel On Windows, Java 6 Update 10 and above includes the Java Quick Starter (enabled by default in the Windows 2000/XP) and installs the Java Quick Starter extension in Firefox. To remove the extension open the Windows Control Panel and double click Java. In the Java Control Panel, click the Advanced tab, click the + in front of Miscellaneous and clear the Java Quick Starter box. [11] Windows Registry extension Installing certain software on Windows can register an extension for Firefox or Thunderbird. For example, a Windows Registry entry to install a Firefox extension can be added under one of these keys: HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions\ HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions\ The Registry entry name will be the ID name or GUID of the add-on and the value data will be the path to the folder containing the extension (see Adding Extensions using the Windows Registry - MDC for details). When Firefox or Thunderbird next starts, it will notice the entry and install the extension. Extensions that are installed this way include the Java Quick Starter extension for Firefox (see above), the RealPlayer Browser Record Plugin extension [12] and the Lenovo ThinkVantage Password Manager extension for Firefox [13] [14]. You will be able to disable the extension in the Add-ons manager but you will not be able to uninstall it because the Uninstall option will be greyed out. If you are an experienced user, you can uninstall the extension by removing the associated Registry entry; otherwise, simply disable it. Note: The program that installed the extension may include an option or preference setting to remove it, so you should try that first. To remove the RealPlayer Browser Record Plugin extension, for example, open RealPlayer, go "Tools -> Preferences -> Download & Recording" and uncheck "Enable Web downloading and recording". [15]"
P.S. (In reply to comment #7) > The discussion continues here: > http://support.mozilla.com/tiki-view_forum_thread.php?forumId=3&comments_parentId=270707 > I took "The discussion continues here" linking to the Contributors forum topic, "Registry editing in the KB" to mean the general discussion on whether any registry edit solutions should be included in the KB. (That forum topic has now moved on to discussing the "The protocol is not associated with any program" article.) > I've changed the draft instructions in the bug URL to avoid registry editing > in the meantime. The bug URL is the "Cannot uninstall an add-on" article. I took "in the meantime" to mean that a final decision on how to edit that article would be made after further discussion. This bug has been resolved "Fixed", though, which is somewhat confusing. If no new article based on the bug summary and description will be drafted, then maybe this bug should be resolved "WontFix"? I was also thinking that the bug summary should be changed to "How to remove the Microsoft .NET Framework Assistant, Java Quick Starter, and other add-ons installed via the Windows Registry" since that would make it easier to find, since similar bugs may be filed in the future. If the scope of this bug has changed to what additional information should be added to the ""Cannot uninstall an add-on" article, instead of drafting a new article, should the summary also reflect that? In any case, I probably should have posted this to the comments section of the "Cannot uninstall an add-on" article's staging copy. I've posted a comment to http://support.mozilla.com/en-US/kb/%2ACannot+uninstall+an+add-on with an x-ref to this bug and added some additional comments. I've also added a comment and x-ref to the Contributors forum topic.
We usually mark the bug RESOLVED-FIXED when the proposed edit has been made, and then VERIFIED-FIXED when it's approved for the KB. Comment 2 and Comment 3 indicate that the proposed edit was made. After further discussion, I decided that the previously proposed edit was not the best idea. So I made a new edit. We should probably change this bug's summary. Please refer to the contributor forum topic for much discussion.
(In reply to comment #10) > We usually mark the bug RESOLVED-FIXED when the proposed edit has been made, > and then VERIFIED-FIXED when it's approved for the KB. When I said, "If no new article based on the bug summary and description will be drafted, then maybe this bug should be resolved "WontFix"?" I was talking about the original bug description and summary, "KB article: How to remove the Microsoft .NET Framework Assistant Add-on", since it doesn't look like a new article will be written on that. > We should probably change this bug's summary. Can you do it, or should Chris have to, since he filed the bug? > Please refer to the contributor forum topic for much discussion. I've seen the Contributor forum topic, "Registry editing in the KB", which includes much discussion about other articles and mentions this bug report but never refers the "Cannot uninstall an add-on" article (until I posted there yesterday with an x-ref to my staging copy comments). I think that comments should still be posted to the staging copy of existing articles when changes are being proposed, so that other editors know what's going on. I've added a cross-reference to the staging copy, linking to the Contributors forum topic.
Sorry for not getting to this earlier. I was sick in bed for the latter part of the week. I was reading through this today, and desperately searching for an MS doc that we can point to. :-) Then I realized: Why not suggest going into the Control Panel, and uninstalling the MS update that added it? From what I've read, this add-on is part of a Visual Studio update, which is a developer tool. I tried it on my Vista VM, and it worked. I took screenshots. Here's the control panel: <http://ilias.ca/screenshots/vista-controlpanel-msaddon.png> So what do you think? P.S. Just so there's no confusion, the monkey rule does not apply to troubleshooting articles.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Addendum: user_pref("general.useragent.extra.microsoftdotnet", "(.NET CLR 3.5.30729)"); is still in prefs.js; so that might have to be removed on a per-profile basis.
Updates besides Visual Studio add this extension - I don't have Visual Studio, but an update to .NET Framework 3.5 SP1 installed the extension. I have the user agent preference, though. Since .NET Framework is something you need for certain programs to run, I don't know if we should say to toss it.
IMO we should list which updates include it, maybe say that rolling back the update is one way to remove it and then refer people to MS support.
I think I disagree... telling people to roll back the update to get rid of the extension seems silly. Unless we have evidence that it can cause problems when disabled, I think we should just tell them to leave it disabled (and bug MS for official instructions). If it really bothers people, they can do a Google search and find the registry key to remove it properly.
ahh true, if it can be disabled then yes, they should bug MS for removal though I think it would still be helpful to list which updates install it so that they have something to take with them.
OK, before we go ahead with this article, I'd like to figure out: * What the extension is doing (http://msdn.microsoft.com/en-us/library/cc716877.aspx) * Why it's installed without the user's consent * Why it's not possible to uninstall it without hacking your computer * Whether or not we should recommend that people just keep it, or that they disable it * If we can get MS to change this behavior as it's potentially harmful to us as well (not just to MS) There's a lot of buzz about this out there -- it even hit Swedish mainstream press. I'm about to reach out to MS about this; will keep you all informed about the process.
Let's see if I can answer these: 1) It allows users to start XAML browser apps by just clicking on the .xbap link and changes your user agent to have your .NET version in it. I don't know what sites use XAML browser apps though. I do know that having a .NET line in your user agent can break some sites' UA detection. 2) It was released as part of a windows update to the .NET framework http://support.microsoft.com/kb/951847 3) Per discussion in #shiretoko, it seems that we don't allow uninstalling via the addon manager for any extensions if the files to be removed are out of Firefox's control (in a third-party directory for example) unless there is an explicit uninstall system in place. 4) I think we SHOULD recommend that people just disable it and then fix their user agent manually. This registry hack is bad news. 5) I believe that kev is working on it, it was brought up in the 3.1 meeting yesterday and I think there are people reaching out to Microsoft.
PS: The reason the UA line in necessary is because these webapps need to know what .NET version you have so they can give you the appropriate version of the app or tell you to update. Also CCing Kev so he can tell us what is probably the best approach.
there's some content being created that outlines what the extension is, what it does, and what the effects of disabling it are. that'll be passed on to djst as soon as it's created. I agree with #19 point 4 in that we should just recommend disabling, and we could provide links to the external sources for people who want more info. that's just my opinion, though, but it feels right to me. we have been in contact with MS, and they are working on a fix for this, but it'll take them a little time to prep it. the method they've used to install the extension is supported by the browser (https://developer.mozilla.org/en/Adding_Extensions_using_the_Windows_Registry), the part that needs work is the user experience and control over the installation, and MS is aligned with changing it to make it much better.
People who are looking to remove it are upset because it was added without their permission, not because of any interference in their browsing experience. Telling users to disable it is not helpful at all. I still think we should recommend removing the update.
(In reply to comment #22) I agree that removing the update is currently the best option for users who want to remove the extension, but with all the work we do trying to get users to keep Firefox up to date I don't think we should *recommend* it either. It still sounds like the best approach is to let users know where it came from (enough people should be able to conclude on their own that they can roll back the update if it bothers them that much), let them know that a fix is being worked on and send them to MS for anything further.
I agree with Lucy's last point - I got the add-on with .NET Framework 3.5 SP1, which I presume (though could not verify) included a security fix or two. Users may be annoyed with MS for giving them an add-on without permission (I can sympathize), but I don't think a Mozilla.com site should be recommending either removal procedures that are available now (registry editing or uninstalling the update).
Yes, we shouldn't recommend removing an update like this since it likely contains numerous security fixes too. I'm still waiting for that official explanation from MS, but until we have that, it seems fair to make the article explain that: * this came with the .NET Framework 3.5 SP1 update * Microsoft installed it and made it impossible for Firefox itself to remove it * it can be removed by uninstalling the .NET update, but it can also be disabled easily from Firefox itself, which has the same effect on Firefox * Microsoft is working on a fix
Two things: Apparently there are other updates it can come with, so we should list as many of them as we know of (there was a Visual Studio update that does this as well, though maybe that's the same thing by another name). If we tell people it can be uninstalled by removing the update that's the same thing as recommending it.
If we give instructions for removal, add instructions for resetting the UA string.
Why does disabling the addon not remove the default pref settings (which is what sets the UA string)? I guess it does remove unchanged defaults (microsoft.CLR.all_clr_versions_in_useragent is gone) but they must re-save the UA one as a user-pref on first run. This would be a good case for the 'when disabled/uninstalled' addon hook going on in other bugs (did that make 3.1?), but that doesn't help us today. We could manually remove user settings for any default prefs we were disabling but that would lead to bad results: prefs would be gone if the user re-enabled the addon, and if the default was an override for a built-in pref and the user overrode -that- it would be gone. We should ask MS to leave their general.useragent.extra.microsoftdotnet pref alone and if they need to add more CLR versions set a different pref with the old versions. Or just remove that option entirely.
I approved the instructions that were already up on the staging version about resetting the user agent and microsoft.CLR preference (if it still exists).
Bo, do you have all the info you need to update the article according to comment 25?
See what you think about what's on the staging copy now. I didn't say "this comes with .NET Framework 3.5 SP1" because according to the comments in this bug, it can also come with a Visual Studio update (although you may get .NET Framework 3.5 SP1 along with that).
Status: REOPENED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
We should list both updates. I also think the section is a little scattered (probably after many revisions). * You don't need to mention that the Uninstall button is disabled, when describing the add-on. * The fourth and fifth paragraph are redundant, and should be combined. * It needs to cut to the chase. For example: "The extension may add some items to Firefox's settings. After you disable the extension, you can remove these items:" Just tell them "Then do this..." (not in those exact words of course. :-) ) Uninstalling the update or disabling the add-on is basically step 1, and removing the prefs is step 2; so we need to format it less like an essay and more like instructions.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Saying that they can uninstall the update is the same thing as recommending it which we all agreed we shouldn't do. If we *must* mention uninstalling the update then we should be explicit that we are *not* recommending that users take such action eg "While it is possible to remove the extension by removing the update that installed it, we highly recommend that you do not remove the update, as you may also be removing other important functionality or security updates"
Let's try again... Introduction: * Text: "If you have Microsoft .NET Framework components installed, you may see the Microsoft .NET Framework Assistant in your list of extensions." * Comments: I think we're safe here. Paragraph 1: * Text: "This extension is installed by a Microsoft update to programs that use .NET Framework components. It is installed at the operating system level, and cannot be removed from within Firefox. Microsoft is currently working on a fix to make this extension removable from within Firefox." * Comments: Here we take care of the various ways this can be installed. So far we've identified the .NET Framework 3.5 SP1 update and a Visual Studio update, but I suspect there may be more. If you are someone reading this, and this statement is meaningful to you, you should already have clue that removing the update will also remove the extension. We also mention that MS is working on making this better. Paragraph 2: * Text: "While you can remove the extension from Firefox by uninstalling the Microsoft update that installed it, disabling the extension will have the same effect on Firefox, and is the recommended course of action." * Comments: Here we explicitly mention that you can remove the extension by uninstalling the update. We also say that we recommend doing something else. Paragraph 3: * Text: "To disable the extension, click on its Disable button in the Firefox Add-ons window and then restarting Firefox. The extension will be inactive after you disable it, but will remain in the Firefox Add-ons window's list of extensions. * Comments: Here we tell you how to do the something else (we assume you don't need help opening the Add-ons window, given that you understand that you have the extension installed). We also re-assure you that your browser will not be tainted by the offending extension while it is disabled, even though it shows up in your list. Paragraph 4: * Text: "The extension may change some of Firefox's settings. After you disable the extension, undo these changes..." * Comments: Here we say to follow through with disabling, without making it seem optional.
(In reply to comment #34) > Paragraph 1: > * Text: "This extension is installed by a Microsoft update to programs that use > .NET Framework components. It is installed at the operating system level, and > cannot be removed from within Firefox. Microsoft is currently working on a fix > to make this extension removable from within Firefox." I think you can drop "and cannot be removed from within Firefox," as the sentences before and after imply it strongly enough. > > Paragraph 2: > * Text: "While you can remove the extension from Firefox by uninstalling the > Microsoft update that installed it, disabling the extension will have the same > effect on Firefox, and is the recommended course of action." > * Comments: Here we explicitly mention that you can remove the extension by > uninstalling the update. We also say that we recommend doing something else. Suggestion: Disabling the extension will prevent it from affecting Firefox until Microsoft provides a way to remove it. [this is what I would prefer to see, but if we want to mention uupdates also include the following sentence] Uninstalling the Microsoft update that included the extension may also remove important functionality or security fixes for .Net framework components and is not recommended.
(In reply to comment #35) > Suggestion: Disabling the extension will prevent it from affecting Firefox > until Microsoft provides a way to remove it. [this is what I would prefer to > see, but if we want to mention uupdates also include the following sentence] > Uninstalling the Microsoft update that included the extension may also remove > important functionality or security fixes for .Net framework components and is > not recommended. I much prefer that text. Saying that disabling the add-on will have the same effect is incorrect, and should not be presented as a solution but something you can do until there is a solution. I haven't seen one user complain about what the add-on does to Firefox functionality. This is 100% about the add-on being installed without permission.
I made the changes. I'll agree that people are probably annoyed at the extension's presence (so was I, which is why I removed it myself), but doesn't this border on monkeying around with the browser? If disabling it and resetting the preferences will keep it from screwing with Firefox, why are we taking pains to mention that you can do something we don't recommend (uninstalling the update)?
Don't recommend uninstalling it, and don't explain that it can be done. The text is fine as it is. Got this from MS (via Shaver): http://windowsclient.net/wpf/wpf35/wpf-deploying-clickonce-ie-firefox.aspx as a description of what the extension does. We might want to link to it for more information about the extension, or use it to build a short one-sentence description of the extension. Re: paragraph 4, is it necessary to reset those prefs in order to fully disable the extension, or is it enough to just disable it?
We want to reset the preferences since it affects the user agent - see comment 19.
I think we're ready, then...
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
(In reply to comment #38) > Re: paragraph 4, is it necessary to reset those prefs in order to fully disable > the extension, or is it enough to just disable it? Disabling the extension is all that's necessary to remove the functionality of the extension. Normally this whould have removed their UA changes had they been static default prefs, but because the extension saved them as a user_pref() the UA change persists even with the extension disabled. The only way to remove the (non-functional) string from the UA is to reset that pref.
Update to .NET Framework 3.5 SP1 for the .NET Framework Assistant 1.0 for Firefox (Date Published: 5/6/2009) http://www.microsoft.com/downloads/details.aspx?FamilyID=cecc62dc-96a7-4657-af91-6383ba034eab It seems that this update enables the Uninstall button for the Firefox extension. According to the download details, "this update must be applied while the extension is enabled in Firefox". I've also added a comment to the staging copy, http://support.mozilla.com/kb/*Cannot+uninstall+an+add-on
From what I could verify with Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 The update requires a reboot. After the reboot, when you start Firefox the extension manager asks you to restart the browser to appy changes. Starting again Firefox, the version of the addon switches to 1.1. From this moment you can uninstall it; from what I could see, the two preferences in the prefs.js are removed in this process. NOTE: for each and every profile (even brand new profiles) the addon is installed. After a restart of the browser it can then be uninstalled. In other words, it allows to be uninstalled but it doesn't allow to deny the installation. Thanks Alice, as usual :)
Thanks for keeping an eye out for this. This bug is verified fixed; so don't worry about having to bring up issues regarding the .NET add-on here. From now on, if you have an update for the article, go ahead and edit the article (and of course, let someone else review it). Thanks again!
There is a pending edit to the "Microsoft .NET Framework Assistant" section of https://support.mozilla.com//kb/*Cannot+uninstall+an+add-on that needs review. The proposed changes to the Cannot uninstall an add-on article are so extensive that a separate "How to remove the Microsoft .NET Framework Assistant Add-on" article may now be in order. In that case, this bug should be reopened. See my comments here: http://support.mozilla.com/tiki-view_forum_thread.php?forumId=3&comments_parentId=270707&comments_offset=20
You need to log in before you can comment on or make changes to this bug.