I have tried to find the registry key
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps
in Windows RT and it appears to be missing. I got as far as the Windows folder, but the Appx folder isn't there. Am I missing something? Does the machine need to be connected to a domain to see this part of the registry? Or can I simply add the subfolder and key and expect it to work?
It turns out that adding the key and value works.
1) Make sure the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx exists. If it doesn't, add it.
2) Make sure the 32bit DWORD HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps exists. If it doesn't, add it.
3) Set the value of that DWORD to 1.
4) Voila! You can now side load your Windows Store App and/or inject a custom data file without a license xml file.
http://technet.microsoft.com/en-us/library/hh824882.aspx
Related
I have a dll which is installed with the initial installation of my app (via an msi file). The dll contains a user key and this is 'demo' for the initial installation. When a user buys a licence he is provided with another dll which contains his name. The second dll is simply the first, rebuilt with a different name so it is the same GUID and file name.
This works fine on my win7 test machine, I can replace the dll in my apps dir and it runs correctly. I have recently provided a user dll to a new client but the replace method doesn't seem to work. He is quite IT literate so I think he is following the emailed instruction (replace the userdata.dll in your app directory with the attached) it does not seem to change the dll. He is using Win8(pro).
I had thought of sending him an Inno setup to copy the user dll into the app dir, Flags:ignorereversion regserver sharedfile
Can anyone suggest a solution or an explanation?
Later...
I have now sent him an Inno setup for the updated dll and this works. If I used the second dll method (a good idea) I would still need to have the user install it.
Rather than replacing the original .dll, why not provide a second .dll with the customer's specific info? The 2nd .dll will unlock features in the original .dll.
For instance, in your original .dll you might check for Customer.dll:
if(TryLoadAssembly("Customer.dll", out assembly)) {
if(Validate(assembly)){
IsUnlocked = true;
}
}
Further recommendations (and untested samples) - have Customer.dll contain a single object implementing an interface:
class Customer : IToken {
GUID Guid {get;}
// other fields
}
To validate:
bool Validate(Assembly assembly){
Type type = assembly.GetType("Customer");
IToken customerToken = (IToken)Activator.CreateInstance(type);
// check some properties
return customerToken.Guid == application.Guid;
}
You say it doesn't appear to be replacing the DLL. Is it UAC redirecting his filecopy into local storage?
If this is the case then the easiest way to deal with it would be to either
1) supply a batch file that can do the file copy, along with instructions to launch the batch file by right clicking on it anc choosing "run as administrator".
2) supply an executable that can do the file copy. You can either include instructions to run the exe as an administrator like the batch file, or you can include a manifest with the application to instruct windows that the file needs to execute as an administrator.
A last option, which might be worth while for troubleshooting would be to get the user to turn off UAC and try the file copy again. If that works then this user will be happy and you know what the problem is and can find an elegant solution for future customers.
I've just looked on my Win 8 laptop and the option for UAC is in Control Panel - User Accounts - User Accounts - Change user account control settings. This will give a slider which can be slid all the way to the bottom to turn off UAC.
(User Accounts really is listed twice.)
I thought this would be dead simple however....
Right, so all I'm simply trying to do is read a value from my registry. I have been through several examples but can't get any of them to work. I've also tried running my application in Admin mode and still nothing. Can someone please help?
From all my examples that I've tried, I'll use the simplest one.
This works:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("Hardware\Description\System\CentralProcessor\0").GetValue("Identifier").ToString()
MsgBox(val)
This (the one I want) doesn't:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient").GetValue("ConfigDB").ToString()
MsgBox(val)
THe latter path and value is one that I've manually created in the registry. I've checked the permissions between the two and they are the exact same. I've also tried running the app as administrator. I get a runtime error on the val= line, it says: Use the "new" keyword to create an object instance.
Any ideas? All the various online examples have failed and for the life of me, I can't figure out why...
Cheers,
J
Well, I have tried your code with a sample application compiled for x86 and, as expected, it fails with a null value exception.
I assume you are building an application for x86 mode and running in a 64bit environment.
Of course, if this is not the case, let me know and I will delete this answer.
In the situation outlined above, the calls to read/write in the LocalMachine.Software registry path will be automatically changed by the Operating System to read/write in the Software\Wow6432Node subkey and thus, your code is unable to find your manually inserted key ("SOFTWARE\PTSClient").
This code will give a null value as return from Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient") leading to the failure to get the ConfigDB value.
You need to add your keys/values to the Software\Wow6432Node path or compile your application for AnyCPU mode or let your code write the value to the register (it will be redirected to the Wow6432Node).
I have inherited a classic ASP application and looking through the code I see a custom COM object reference
Server.CreateObject("DBaseManager.Recordset")
Now, unfortunately looking through to source code there are no .dlls provided so therefore the COM dll must still exist on the live server.
In order to get the code working on my Dev Server I need to get a copy of the dll so I can register it on my Dev server.
Does anyone have any recommendations about how I might be able to find the COM dll that makes the above call?
Thanks and best wishes
Mark
Registry search - under HKEY_CLASSES_ROOT, locate the DBaseManager.Recordset key. Under that key, there should be a CLSID key, with a default value containing a guid.
Now, search for that guid under HKEY_CLASSES_ROOT\CLSID. There should be a subkey under that key called InprocServer32 (if it's an in-process COM library), which in turn should have a default value giving the path to the DLL.
Of course, if the DLL in question is part of a larger product or SDK, merely installing the dll on your dev server may not be sufficient. You may have to locate and install the whole product/SDK in order for it to actually work on another machine.
I'm just familiarising myself to edit registry in VB. I am having a problem with changing a value in the HKEY_LOCAL_MACHINE key. When ever I change a value at runtime it always assumes that I am going in the "Wow6432Node" key, even though I don't put that in the parenthesis. Example: My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL", "CheckedValue", 1)
and it doesn't change the value in the string above, but changes it as if I have put "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL" in the string.
The program is running as administrator.
That's called registry redirection. In 64 bit Windows some registry keys (including HKLM\Software) are redirected for 32 bit applications. If you changed the build properties on your VB.NET project to x64 you would see it write to HKLM\Software. You can access the non-redirected keys using flags, but I believe those are only available for the unmanaged APIs.
But the short answer is you not doing anything wrong, and that how it is supposed to work.
I am writing an installer using Wix 3 which installs a plugin to a 3rd party application. The application uses a group of registry keys to detect installed plugins. Each plugin is required to add a new subkey with a numerical name from 0-9 to the HKEY_LOCAL_MACHINE\SOFTWARE\Vendor\App\Plugins. The key contains a single string value which is the ProgId of a COM component which the application will instantiate. So for example I would need to add the following key to install my plugin:
HKEY_LOCAL_MACHINE\SOFTWARE\Vendor\App\Plugins\0
REG_SZ ProgId "MyCompany.MyPlugin"
However, if the 0 key already exits, my installer needs to be smart enough to create key 1 instead of 0 and on down through key 9. Is there a way to achieve this using the Wix syntax? I know I can write a custom action to do this, but if at all possible I would like to avoid it.
You could use RegistrySearch to find the first empty value. But it would be easier to use the approach I describe at http://www.joyofsetup.com/2007/07/01/semi-custom-actions/.