I load unpacked Microsoft Edge extension successfully. But when I restart Edge, it shows:
We've turned off extensions from unknown sources. They might be risky so we recommend keeping them off.
There are two buttons: Turn on anyway, Keep them off. But I want to Keep them on, in other word, I want my extension to be load automatically when browser restart, no need to click the Turn on anyway button.
How can I do that?
Confirmed from Microsoft that unpacked Edge extensions cannot be loaded automatically on restart.
You can't permanently activate Edge extensions that are not in the Store due to security reasons.
https://learn.microsoft.com/en-us/microsoft-edge/extensions/guides/adding-and-removing-extensions
Related
I don't want to find some disabling of gatekeeper where I just turn it off completely.
However, I use SQLiteStudio probably more often than majority of the applications on my computer, but every single time I open it (which I try to avoid and just keep it open constantly) it requires that I go into Security & Privacy and hit "Open Anyways" to force it to open since it's apparently from an unidentified developer...
Anyways, I'm hoping there's some fix or something I can do to permanently disable the warning for this particular application only?
Most other applications when I download them and open them and they have that issue it only occurs the single first time I open it - and then when I hit "Open Anyways" it disables the warning from then on. But this application is the exception and I'm really hoping for a solution. Any help???
I have a virtual box with and immutable type storage which I need to change, so I'm trying to set the storage type back to 'normal' so I can persist my changes (before making it immutable again)
With the VM shutdown I run:
VBoxManage modifyhd file.vhd settype normal
VBoxManage showhdinfo now correctly shows the type as normal,
but changes are still not persisted after terminating the machine.
What could be going wrong here?
It is far easier to use the Built-in VirtualBox Media Manager....
Make sure to update the VB when starting and before firing up any VM's Click FILE and then MEDIA MANAGER.
Select your appropriate VHD or whatever format disk you are using and choose the appropriate radio button, in this case it would be NORMAL
OK it and start the VM. You may have to start it from the VB Main Menu twice. Especially when switching back and forth from/to Immutable (Read Only) and Normal (Read/Write).
Hope that helps. Otherwise when using the CL you should use --Normal and --Immutable
The missing step is to detach and reattach the disk. Otherwise, the VM will keep on using the differencing image.
In the Virtual Media Manager,
Right-click on the differencing image
Release...
It also helps to delete (Remove) the differencing image. Otherwise, VirtualBox will keep creating more, even after you're back to Normal.
In your VM's Settings > Storage
Add hard disk (Click square-plus icon at the top of the tree view)
Select the disk you previously changed back to Normal.
(i posted this question on VMware community forums, with no response)
All of my developers use VMware workstation 11 for running their Visual Studio development environments in Windows. I originally created a base VM, and then simply shared it around to all the users, unbeknown to all the issues it would cause with computer name conflicts, joining the domain, etc. Apparently I didn't 'sysprep' it. Someone with some VMware knowledge tried to help me out to set it up, but im still not sure if it is 100% correct.
I am now at a point where I need to make changes/updates to the base VM (new VS, run Windows Updates, etc) and distribute a new one around to all the developers again, and I need some help to make sure I do it properly this time:
I have 2 VM images currently: 1) a ‘base’ one that opens up to this screen http://screencast.com/t/tBO0IUvwtpbY and 2) one that opens up to this screen http://screencast.com/t/DLV71PeNygrk . I’m assuming it is the ‘base’ one that I make the ‘edits’ to?
If I do edit the ‘base’ VM, what option(s) should I choose in that sys prep dialog?
Once I make the necessary updates to the base VM, what do I need to do to 'prepare' it for distribution to my developers (do I need to run sys prep, do I need to make a copy of VM beforehand, etc)?
Currently the VM has 2 HD's: 1) used for the OS and applications (Persistent and non-Independent), and 2) used to store data files (Persistent and Independent) . Is this the best way to set it up and use the VM (and then use 'snapshots' to revert back to previous states), or should the OS disk be set up as 'non-persistent' after the user has set up the VM for first use (i.e. joined the domain, set up VS Workspace, etc) ? Basically we have had a few scenarios recently where the OS and VS have been corrupted and it took the devs a while to fix it, so I want them to have some sort of way to revert back to a known clean working state.
Thank you
In answer to your questions you are on the right track.
the first screen that opens is correct, customise everything you require in the OS then run the OOBE before distribution
Choose OOBE and tick Generalise, then choose shutdown.
Once the VM is shutdown export it and pass it round your developers. they will need to complete the wizard and then join to the domain if required, this will ensure all the sids are different on each server, remember they must still change the Servers name before joining the domain
Snapshots are best, if your dev needs to reboot etc he doesn't want to loose his changes, he then has the option to revert to a snapshot.
Hopefully this has answered your question, let me know if there is anything else you need :)
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
I use AVG and it recently detected a virus. It has before ;) but this was the first time I noticed this.
When I went into the folder containing the virus, AVG immediately, automatically, detected the virus without me even clicking on the application. So I though how could it know a virus was there even when I did not even click (single click) on it.
The only possible answer is that it continuously checks the explorer folder location of all windows and scans all the files in the folder. But how does it see what folder is being viewed by me?
Please explain (if possible) with a C program that does what ever AVG did.
Also : I use Windows if that helps.
When you open a folder a bunch of file system operations is executed (you can use tools like FileMon or ProcMon to take a look at this). Your AV software monitors file access.
There are multiple ways to do this monitoring, e.g. Filter Drivers - you can find a great sample at http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial
So when you opened the folder, AV software noticed that you opened a directory, consulted its own data, and informed you about the virus.
I say 'consulted its own data', as AV tools usually don't scan files on access - they do it when the files are written to, as it doesn't make sense to scan files which were marked as clean if they haven't changed since the last scan.
Most virus scanners operate on the principle of API hooks/filters. Whenever windows needs to process a command, like opening a folder, clicking a window, executing a file, etc it generates an api call along with some information like the window coordinates clicked, or a string representing a file. Other programs can request a hook into one or more of these functions which basically says 'instead of executing this function, send it to me first, then I might send it back'. This is how many viruses work (preventing you from deleting them, or copying your keystrokes, for example), how many games/apps work (keyboard, joysticks, drag-and-drop), as well as malware detectors and firewalls.
The latter group hooks the commands, checks any incoming ones to see if they're on the level, then either allows them to resume or blocks them. In this example, opening the folder likely triggered a syscall to parse a directory, and the scanner parsed it too (eg 'realtime protection'). To view all of your hookable functions as well as what is using them, google for a free program called 'sanity check' (previously called 'rootkit hook analyzer'). Most of the red entries will be from either windows firewall or avg, so don't worry too much about what you find.