I created an Edge extension what if I install manually works perfectly. But if I want to install by registry settings it doesn't work. I tried to set up the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Edge\Extensions
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Edge\Extensions
key aaaaaaaaaabbbbbbbbbbcccccccccc
path: C:/extensions/extension.crx
version: 1.0
OR
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Edge\ExtensionForceInstalllist
key 1
value aaaaaaaaaabbbbbbbbbbcccccccccc;C:/extensions/extension.crx
but it doesn't work.
The group policy you mentioned is indeed for installing extensions silently, but it has some limitations. For example this paragraph in the documentation description:
In this case, I think you need to check if your current environment matches this situation. In addition, if you need to publish your extension to the Edge Add-ons webstore, you can refer to this document: Publish a Microsoft Edge extension.
The problem was solved to place the crx file and update.xml a file server what is reachable from everywhere. The firewall caused the problem.
Related
When working locally, how can one direct azure-core-tools to download "Microsoft.Azure.Functions.ExtensionBundle" from a self hosted endpoint instead of "https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/index.json"?
In a enterprise environment, internet proxy often bock access to the internet and artefact have to instead of hosted on the intranet.
Thanks to #DeepDave-MT comment I was able to figure it out.
Upload the extension bundles and index.json somewhere following strict paths:
/Microsoft.Azure.Functions.ExtensionBundle/<version>/Microsoft.Azure.Functions.ExtensionBundle.<version>.zip (can be downloaded from https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/2.13.0/Microsoft.Azure.Functions.ExtensionBundle.2.13.0.zip)
/Microsoft.Azure.Functions.ExtensionBundle/index.json (you use that file https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/index.json)
Set the an environment variable before starting az function core tools FUNCTIONS_EXTENSIONBUNDLE_SOURCE_URI=https://example.net/some/path/
Az core tools will first fetch the index.json, checking the versions listed there and then downloading the zip.
Noticed that Azure DevOps is no longer showing the menu options in Project Settings for the Extensions.
Does anyone else see this or know why?
I am unable to update settings for the installed extensions.
You can manage the installed extensions in the Organization settings.
Go organization settings--> Extensions under General. See document here for more information.
I have seen the same thing, and it only occurred recently. Yes, the org level extension management is still there, and that only allows for managing which extensions are available to use.
The configuration for the extension usage within each project was a separate section in the project settings - this is missing entirely. We have need to modify one of our extension configs and can no longer access it to do so.
I believe this must be an Error of type PEBKAC coming from a recent MS update to DevOps.
For some reason I cannot get this to work. I'm following the exact procedure described here
http://developer.chrome.com/extensions/external_extensions.html#registry
And I still cannot get the extension listed. If I install it manually, using "Add Unpacked Extension" it works just fine.
Any help would be greatly appreciated
One of many writeups on this subject:
Google on Friday announced that it is changing its stance for silently
installing extensions in its browser. As of Chrome 25, external
extension deployment options on Windows will be disabled by default
and all extensions previously installed using them will be
automatically disabled.
You're much better off submitting your extension to the Chrome Web Store. If you really want to install off-store, consider inline installation.
I have been struggling with installing an addon via the registry as well. I was successful with installing an addon without adding reg keys. And using the preferences file.
I extracted my extension to Local\Google\Chrome\User Data\Default\Extensions\${ADDONID}\${VERSION}
I then added my extension directly to the Preferences file in Local\Google\Chrome\User Data\Default under the section extensions settings ${ADDONID} <-- add your extension. Compare the Preferences file to an instance you have already installed your addon. And copy that to the Preferences file along with the extension directory on a fresh install. And it should work.
This thread gave me some direction:
https://superuser.com/questions/462804/how-to-copy-an-extension-from-one-chrome-installation-to-another
I'm trying to build a Web Deploy package via msbuild on a new machine and it's not working. It builds fine on other machines, but here I get the following vague error:
...\Microsoft.Web.Publishing.targets(2767,5): error : Filename: redirection.config
...\Microsoft.Web.Publishing.targets(2767,5): error : Error: Cannot read configuration file
...\Microsoft.Web.Publishing.targets(2767,5): error :
...\Microsoft.Web.Publishing.targets(2767,5): error : Unknown error (0x80005000)
I'm not sure what 'redirection.config' is, and the line reference to the .targets file doesn't help at all.
How can I fix this?
redirection.config is a file that lives in the IIS configuration directory, typically %SystemRoot%\System32\inetsrv\config. Here are two possibilities:
The account building your project doesn't have access to the IIS config dir. This might happen if you have an automated build identity with special permissions, or you if you need to start Visual Studio as an administrator.
You don't have IIS installed at all on the new machine. Check to be sure the IIS config directory, and redirection.config in particular, even exist. If not, you'll need to install IIS.
If you receive this error when deploying with Release Managment (via IISConfig.exe) be sure that the deployment agent service account is in the local Administrators group. You may need to restart the deployment agent service.
Similar Issue resolved below - Might help
Insufficient Permissions Problems with MSDeploy and TFS Build 2010
For me, simply running visual studio as admin gave it the elevated permissions it needed to operate against this folder.
May work for others.
I got this error when I tried to use a relative path for the contentPath setting. I fixed it by settings the contentPath to the full path of the folder. Without the full path, the contentPath provider thinks it is a site path or application path and looks for it in in the IIS configuration.
This error just appeared to me when my C# project was referencing the Microsoft.Web.Administration, Version=7.9.0.0 assembly. It looks like this assembly only works with IIS Express. For IIS, we must use Microsoft.Web.Administration, Version=7.0.0.0.
After hours of testing and troubleshooting this problem turned out to be an issue with the users profile.
This was found by logging in as myself and I didn't receive the same issue.
To fix this issue:
Log into the machine as an administrator and delete the contents of the corrupt profile from C:\Users (or rename the folder to username.OLD)
Open up the registry and navigate here – HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList
Find the corrupt profile and rename this to .OLD or remove it.
You can read more about it at this article.
As this is high in search engines when looking for this error, I'll post my solution.
I used Azure Pipelines to release the app to IIS and had this error. My issue was that I mistakenly used Build Agent job instead of Deployment Group job when configuring the release pipeline.
On server 2012 this error can be caused by UAC which needs to be disabled via the registry.
This article explains why...
https://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
change DWORD "EnableLUA" from 1 to 0
I have a small solution that is composed out of 2 main projects a Mvc4 Web Api and a silverlight 5 Application. I've configured and deploy the application initially on the Azure platform and it all went great, but ever since when I deploy again the silverlight project does not get pushed and the online site has the old version.
I should mention all works great with the azure simulator on my local dev machine.
Anybody had a similar issue?
Regards,
I would suspect first (as Simon suggests) that the browser likely still has the previous client cached and loads that instead of downloading your new client.
You can use the version number in the code on your page that hosts the silverlight app to help. While it's easy for you to clear the cache - you don't really want to have to tell users to do that whenever you update.
Set the version to whatever your latest assembly version is (silverlight client project assembly), this will force the browser to download the client if the cached version is a lower number.
<param name="source" value="AppPath/App.xap?version=2.0.0.6"/>
Ok,
So after pulling my hair out, I finally figured out.
I have to change the build configuration to release in VS do a rebuild and then do publish because apparently the azure project does not do rebuild on the project when you publish it.
To solve this issue you'll need to identify the source of the problem (is it a client side problem where you have a caching issue or not). Even though you say caching isn't the problem we'll need to be sure about this first.
What I suggest is that you do the following first:
Activate Remote Desktop on your role
Connect through RDP and save this file to the role: http://support.microsoft.com/kb/841290 (fciv.exe)
Find the *.xap file (usually in E:\sitesroot) and get its checksum (using fciv.exe)
Modify the Silverlight project locally (maybe change a label or move around an element) to make sure its hash has changed.
Redeploy the application
Connect through RDP and use fciv.exe to get the checksum of the *.xap file once again
Compare both checksums
If the checksums are different, then it means that the deployment worked correctly and the Silverlight xap has been updated. If the checksum is the same, the problem lies with the deployment.
Please let us know the result so we can help you find the solution.