Microsoft .NET Framework Assistant 1.3.1 Add-on Removed by Adminstrator

This add-on Microsoft .NET Framework Assistant appears to have been recently removed. I work on enterprise software which is deployed via ClickOnce, and a customer reported to me on September 30, 2015 that this add-on is no longer available. We depend on this add-on to allow our customers to be able to use our software in Firefox.

https://addons.mozilla.org/en-US/firefox/addon/microsoft-net-framework-assist/
The page now reports that it was removed by an administrator (not by Microsoft?). Does anyone know how to find out more information about this?

I currently have this add-on install in my instance of Firefox (Microsoft .NET Framework Assistant 1.3.1.1-sign - Last updated Monday, June 1, 2015), and it is still functioning normally.

Any information about this is appreciated, so far we have no explanation to provide our customers.

See https://discourse.mozilla-community.org/t/microsoft-net-framework-addon-weirdness/4430

What did the addon do? I think what it did should be possible via js-ctypes.

This issue continues to be a problem for thousands of our users. Recently Chrome has deprecated more of the 3rd party ClickOnce extensions (due a new security requirement that extensions should not modify the userAgent string). We are in a tough position again with no Microsoft supported ClickOnce plugin outside of IE/Edge.

We contacted Microsoft about this issue, and learned that Firefox recently added native partial-support for ClickOnce applications. My understanding is that the Firefox implementation only supports ClickOnce applications which are deployed in offline mode. This does not support client-server applications.

The following is an explanation from a Microsoft Support Engineer which we contacted that describes how a mismatch between the <deploymentZone> and <applicationZone> (i.e. client-server) fails to launch in Firefox. Will Firefox fix this issue, or restore the Microsoft supported add-on?


From Microsoft:

Deployment and application does not have matching security zones. deploymentZone=System.Security.Policy.Zone version=“1”
<Zone>Internet</Zone>
</System.Security.Policy.Zone>
,applicationZone=<System.Security.Policy.Zone version=“1”>
<Zone>MyComputer</Zone>
</System.Security.Policy.Zone>

We also compared the logs between Online and Offline CO apps. ClickOnce provides an implementation of the IE mime handler interface for the mime type application/x-ms-application which is associated with .application files on servers hosting ClickOnce application. Hence when a user clicks on a .application in IE our mime handler is invoked which downloads the .application file and fires up the ClickOnce install.

When a user clicks on a .application in FireFox the FireFox equivalent of the Open/Save dialog comes up. Once the .application file is downloaded to the local machine (to the Firefox cache on Open and to a user specified location on Save) it is run form there firing up ClickOnce. ClickOnce now parses the locally downloaded .application and tries to download the actual application manifest it refers to. If the .application contains a relative path to the application manifest ClickOnce will try to find it relative to the .application in the FireFox temp folder and it will fail. If it is a full Url to the application manifest ClickOnce fails anyway, this time due to a security check we have that does not allow the .application and the corresponding application bits to be in different security zones.

The key summary is that ClickOnce applications will work using Firefox browser only when it is deployed in Offline mode i.e. the tag is needed to overcome the relative path issue.

I should also mention that I have a local copy of the .xpi file for the add-on, and it continues to function normally in current versions of Firefox. So it seems like there is not a technical reason why the add-on would not continue to work if it was just restored to the add-on store.