I'm experiencing the combination of a locally installed Microsoft Edge Chromium Enterprise Edition and Microsoft App-V. I try to App-V a browser plugin for a locally installed Microsoft Edge Chrome Enterprise.
I have an App-V bubble and Internet Explorer is started with this bubble in the background using the /appvve command-line option.
My first suggestion was:
Replace the file path to iexplore.exe to the new file path of msedge.exe, eg.
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --site-per-process -url https://www.website.com /appvve:[App-V PackageID]_[App-V PackageVersionID]
This works only when MS Edge has no running instances already.
The --site-per-process option should help isolate the process of Edge Chromium.
When Microsoft Edge is already opened, there is some magic: the bubble is active for some seconds and after that the App-V bubble is closed.
ProcessExplorer of SysInternals does a great work: it tells me a secondary process of Edge Chromium is started with the bubble on the background.
Then the subprocesses of the secundary started instance are brought to the primaraly started instance and when this all is done, the secondary started instance - including the App-V bubble - is closed.
The webpage is opened, but the connection to the App-V bubble is lost.
The same happens when MS Edge-with-app-v is running bubble-a and you want start a secondary instance with bubble-b.
Could anyone tell me how to tell MS Edge to really isolate its processes and how it could work with multiple loaded App-V bubbles?
The only way I have successfully got around this is with the --no-sandbox, --app, and --user-data-dir switches.
For example:
C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --no-sandbox --user-data-dir"%LOCALAPPDATA%\Microsoft\Edge\AppV --app="https://www.website.com" /appvve:[App-V PackageID]_[App-V PackageVersionID]
This opens up the page in an App window and uses its own directory so the process isn't merged with existing or new instances of Edge that launch in the default directory.
I found this kept crashing until --no-sandbox was introduced. however, I'm a little on edge as the Sandbox helps keeps this secure. I'm also wondering how the Sandbox is interfering with App-V.
This is a workaround, but I do think MS will need to investigate this further as clearly the --site-per-process isn't separating each tab, at least not how we would expect.
While I have not tried to virtualize this under App-V, I am aware that others have done so, for example NickIT.
Off hand, I would guess that RunVirtual is what you are looking for.
Related
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
I always debug the WebView control with VS, I refer to the this official document Debug a WebView control in a UWP App.
Recently, I found there is a best way to debug the WebView control by using the
Microsoft Edge DevTools Preview App.
The problem is that it seems the only way to install the tools is Microsoft Store. Unfortunately the Miscrosoft Store is blocked on my machine, I want to know is there any other way to get the Microsoft Edge DevTools Preview tool? Any help would be appreciated, thank you in advance.
I found this article https://windowsreport.com/download-microsoft-store-apps-without-store which seems to show a way of doing this.
I cannot state if it definitely works yet as I have to wait for my IT to department to decide if it can be allowed.
Steps are:
Visit https://store.rg-adguard.net/
Enter https://www.microsoft.com/en-gb/p/microsoft-edge-devtools-preview/9mzbfrmz0mnj
Download the file ending in appxbundle (to it's own directory not just "downloads")
Open Powershell as Admin
Execute something like Add-AppxPackage -Path "C:\Users\WindowsReport\Downloads\ee2546d7-f0e5-4aa2-be54-032299162322" (change path to the download directory you used earlier)
If you get errors you may need to download additional files from the same place you got the appxbundle file
I had been happily using Java live reload while debugging my Vaadin application over the past few months.
Today, after I started my browser and directed it to my locally running Vaadin application I got a popup in the lower right corner stating:
Java live reload unavailable. Live reload for Java changes is currently not set up. Find out how to make use of this functionality to boost your workflow. Read more
Clicking onto the read more link (pointing to 'https://vaadin.com/docs/v14/flow/workflow/workflow-overview') just brings me to a "404 Page Not Found" error page.
So - two or actually three questions:
what could cause my live-reload functionality go missing? I am using MS Edge and the Live-reload plugin is enabled (and it used to work until yesterday).
where has the page gone explaining how to set that up?
and finally: Any idea, what to check or fix to get this working again? I consider that pretty essential functionality for efficient UI development!
For question 2, you can find the documentation here: https://vaadin.com/docs/v14/guide/live-reload
I am doing a POC in PWA and service worker, i hosted to application in localhost and tested in Chrome everything seems to working fine even the indexed db is getting listed properly.
to test the offline functionality :
in Inspector > Network Tab > Offline ( check the option )
When am in Edge i didn't see this option so tried disconnecting the network but still because it reading from localhost everything is working directly and reading from server.
To check the Indexeddb and all i installed the MS Edge DevTools preview, still am not able to see the DB and Store
Is there any way to test this in Edge
At present, Offline mode is not available in MS Edge.
If you want to see index db then you can open the developer tools and go to the debugger tab.
It looks like below.
You also not need to install developer tools additionally because by default it comes with Edge. You can directly use it.
You can try to check on your side. Let us know if you still have problem in finding the index db in Edge, We will try to provide further suggestions.
I am building a static app with PouchDB on Google AppEngine.
When I open the site in a browser window, it is showing a version I uploaded several hours ago.
If I open the site in an incognito window, the updated version is displayed (therefore I don't think it is actually an error in the console).
I put a new version number in app.yaml
I have migrated all traffic to the new version.
I have cleared my cache, deleted cookies, checked my application data, everything. I even reinstalled Chrome and Firefox.
I updated my Python version and my Google AppEngine Launcher yesterday; the problem pre-dated that update.
Also: just discovered that if I go to the URL of the updated version
http://4.[app-id].appspot.com, it displays the correct, updated version.
This is happening in Chrome, Firefox, and Edge.
Edit: probably should have mentioned that my site uses Service Workers and IndexedDB. I assume my service workers are caching the previous version, but I would have thought that Ctrl + F5 would clear the cache and show the new version.
I think it must be the Service Workers caching the pages (which is, after all, what they are supposed to do). This is actually really annoying when you are developing though.
A guy called Rich Harris has documented this behaviour and some workarounds on a Github Gist.
Reloading the page doesn't behave as you'd expect
If you make a change to your service worker, then reloading the page
won't kill the old one and activate the new one (it detects the change
by requesting the service worker file each time and comparing the old
and the new byte-for-byte), leaving you somewhat confused as to why
your changes haven't taken effect. This is because the old window is
never actually closed, meaning there's never a time to swap them out –
you need to kill the tab completely then reopen it.
Or you can have the browser do that for you by going to the
Application tab in devtools (in Canary, not stable Chrome yet), going
to the Service Workers section, and checking 'Update on reload'.
UPDATE (13 Nov 2017): This functionality is now available in Chrome, so you don't even need to download Canary.
And here's which bits of the application cache to clear: