I made some changes to my camera driver inf and added few registry entries under [cameramodel_Device.AddReg] (this is after [cameramodel_Service_Inst] in the inf file).
But after installing this modified inf, I don't see the entries that added in the registry under camera GUID --> Device parameters.
Can anyone help me where I should add my entries in the inf to get the custom entries under Device parameters?
Related
We have some hyper-v server images that if possible we would like to not rebuild. However the original machine they were installed on is no longer available.
So we have 1 vhdx and 8 avhdx. The vhdx is the virtual disk and the avhdx are check points if I remember correctly.
The process I used to build these machines was such as base install...checkpoint..install SQL Server...checkpoint...install visual studio...checkpoint etc...
I created a new vm on my windows 8 box and in the create wizard I told it to use an existing vhdx then pointed to my previous one.
The system boots and takes the correct password. However it comes up at the base install point. The checkpoints do not show in Hyper-V manager and consequently they do not get applied to the VM.
Now I have found that there is a sort of checkpoint database (xml) and several related folders in
C:\ProgramData\Microsoft\Windows\Hyper-V
thinking maybe there are some pointers I could realign but it seems editing them is not supported.
I also tried under the settings option of the test vm to change the checkpoint location. That seems to be a place for checkpoints to be stored and it doesn't seem to pick them up if any exist........this behavior makes sense as the pointer xml / database thingy is where that information should come from.
So is there a way to get these checkpoints associated / recreate / make use of these existing hyper v machines?
Thank You
I need to set the version visible in the 'Programs and Features' dialog in Windows. I know that this version doesn't have to follow the major.minor.build.revision restriction (for example, wxPython shows '2.8.12.1-unicode' in its 'Version' column), but when I attempt to set the Version attribute in the Product element I get the following error:
Product.wxs(50,0): error CNDL0108: The Product/#Version attribute's value, '2.3.4.0-55628f206205451282ae6060d9305254bd79cb87', is not a valid version. Legal version values should look like 'x.x.x.x' where x is an integer from 0 to 65534.
There must be a different property but I can't find it in the Wix documentation.
How do I set this version visible in Wix to an arbitrary string?
EDIT:
See the image below to see some of the different version schemes that don't follow the Windows Installer standard (wxPython, Windows Driver Package*, Windows Mobile 5.0 SDK).
Windows Installer doesn't support having separate product version and display versions.
If you are using the .Net setup project look for Version under "Deployment Project Properties".
I am not entirely sure what you are referring to with "Programs and Features"? Are you talking about "Add/Remove Programs" in Windows, or are you talking about the dialogs in your setup?
I suppose you can have a look here: Configuring Add/Remove Programs with Windows Installer, but without knowing more I don't quite know if this is what you are asking.
Please be aware that this list of programs and applications does not come from just one registry location. I do believe that it is not possible to override the version field for Windows Installer packages whether they are built using Wix or other tools. If the installation is done with non-MSI setups, I suppose they can set the version field as they see fit, but Windows Installer enforces restrictions. Perhaps you can set the ARPCOMMENTS property to a value indicating what you want to indicate.
The underlying MSI property that shows up in Add/Remove Programs aka Programs&Features is the ProductVersion property and it does have to follow a numeric format:
http://msdn.microsoft.com/en-us/library/aa370859(v=vs.85).aspx
You may be able to get a text version to show if you create a DisplayVersion text string in the Uninstall registry key. I suggest you look at the wxPython entry in the Uninstall key to see what's in DisplayVersion rather than in the binary Version value.
When I update my system with a new NK.bin file, I want to keep same language configuration I had before.
A suggestion was made that I read the information from the registry, then copy my new NK.bin file, replacing the current NK.bin (yes, you can do this while windows is running using that NK.bin file).
When this is done I write the values back to the registry.
My understanding is that this will affect the NK.bin after restart. This mean that the system shouldn't notice here that it is a new NK.bin file during restart.
And it works fine, the registry changes its value. HOWEVER, when I'm doing the update, it ends with a restart of the system.
When I login after that restart, the regsitry is changed to correct/loaded value, but it shows wrong language. Then after another restart the language is correct.
I want to handle this directly, making the system start with correct language from the start.
The code below shows last step of my update before restart. The new NK.bin file is just copyied and replaced the old one.
Should also say that following register is changed but wont take effect until the second restart:
cSysLang = #"MUI";
cDefaultLCID = #"nls";
cTouchCalibrationData = #"HARDWARE\DEVICEMAP\TOUCH";
cKeyboardDefaultSubKeyStr = #"keyboard layout\Preload";
cLangSubKeyStrCurrUsr = #"MUI";
cLangSubKeyStr = #"nls\overrides";
private void LoadDataAfterInstallation()
{
//langauge
Microsoft.Win32.RegistryKey regLanguage = Microsoft.Win32.Registry.CurrentUser.OpenSubKey(cLangSubKeyStrCurrUsr, true);
if (!(languageRegInfo==0))
regLanguage.SetValue("CurLang", languageRegInfo);
First let's discuss how a persistent registry works. I'm going to assume this is a newer device and it's using a hive-based registry (there was an older mechanism for persistence that worked in a completely different manner, but I've not seen much of it since the 4.x days).
The device has a baseline registry hive that the OS loads up when it's first booted (system.hv). It then applies your changes (user.hv) to that baseline registry. Now before either of these is loaded, the OS should be doing a checksum of the NK.BIN, and if it's different, it should toss out both and recreate them. A registry from an old OS is not guaranteed to be valid for a new OS, and for sanity's sake they should never be used.
So the order should be something like this:
Read registry
Update NK.BIN
Restart
OS deletes the old registry
OS loads the default language in the default registry
Write your registry values for the new language
Restart
OS loads new registry changes
OS loads new language
This, I think is where you are, yes?
The second restart is necessary for the OS to be able to see the registry changes you made. You may be able to avoid the second restart (I'm not sure - it's been years since I tested this and don't recall) by broadcasting a WM_SETTINGS_CHANGE after restoring the value. As a definitive resource, look at the Control Panel source code to see what it's doing when the user changes the OS language with the UI.
If you are using MUI I think you can't avoid the restart. Some settings may be refreshed dinamically, but language isn't. But you can programmatically restart your device as soon as you re-imported the registry. Isn't that an option? You can include a key in the reg inside the image and change it when boot is completed. If you have the image value it means that the registry need to be restored. You restore it, setting the new value, and then automatically restart the machine. This should be a minor inconvenience for your users.
Using WiX 3.5, I have an MSI with instance transforms allowing me to install the software on the same machine with different product names. To do this, I have a "hard-coded" list of product id's and names in the .wxs file defined conditionally. However, I have only the single Feature-ComponentRef definition that includes both file and non-file resources.
Installation appears to work fine, but uninstalling the instances demonstrates the behaviour mentioned in these two sources:
http://msdn.microsoft.com/en-us/library/aa367797(v=VS.85).aspx
and
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simple-Addition-to-WiX-to-Make-Them-Easier-td708828.html
Specifically, none of the non-file resources (in this case, registry entries) get uninstalled save the very last instance of my application. (i.e., if I uninstall in this order: instance1, instance2, and instance3 - only instance3's non-file resources are removed.
I am presuming this is related to not having unique GUID's for nonfile components (whereas this isn't an issue for file components)
So, I was wondering whether a valid approach would be to define a single .wxs file with one product id, name and one set of features, but have a custom bootstrapper generate new GUID's for the product and non-file components which then get inserted into the MSI database at runtime? i.e., Then when it comes time to uninstall or update, I would query the registry for installed instances and retrieve their GUIDs then.
This would permit instances to be created at runtime rather than hardcoded in the .wxs in advance, and to be uninstalled cleanly.
Does that make sense? Will Burn make everything better? :)
As of version v3.6.1511.0, there is now a "MultiInstance" attribute for components. This allows a guid to be generated on the fly for each instance as per Josh Rowes suggestion in his post to the WiX mailing list (see the link in the OP). I have tested and this works correctly to cause registry data to be removed when the current instance is uninstalled, and not when the LAST instance is uninstalled.
You don't need to have unique component ID's but you do need to have unique registry keys. Check out:
Authoring Multiple Instances with Instance Transforms
The article mentions:
To keep the nonfile data of each
instance isolated, the base package
should collect nonfile data into sets
of components for each instance. The
appropriate components should then be
installed based on conditional
statements that depend on the instance
identifier.
I actually don't know what they are talking about there. I created n-Tier multiple instance installers where all the files were isolated by unique INSTALLDIR ( type 51 custom action at runtime to mutate the destination based on the InstanceID ) and all the registry data was mutated using the InstanceID as part of the path as mentioned in the article. I supported up to Sixteen unique instances with unique configuration data and unique version #'s ( each instance could be serviced via major upgrade apart from the other instances. ) All of this was to support a SaaS deployment model for an nTier application and I never ever had to create components with unique GUIDS and/or Conditional expressions.
The only thing wonky I had to do was on the client side they wanted a Shortcut on the desktop. (The Client supported multiple instances also because a site might have v1.0 in Production and v1.1 in Test )
Because I couldn't mutate the folder name (fixed) and because MSI's ShortCut table doesn't support formattable, I had to write a custom action to author the ShortCut dynamically at install table using the InstanceID into a TEMP table and then MSI created the shortcut for me.
I'm installing an Active X control that contains some COM servers. I'm using InstallShield's COM Extract at Build option to generate the registry information. This results in a lot of entries in the Registry and Class tables. (The extracted information is pretty much the same using Wix).
It appears that my COM Sever is correctly being installed except for an additional value called "InprocServer32" in the InprocServer32 key that looks like this:
HKCR\CLSID\{MY-COM-GUID}\InprocServer32
(Default) = C:\Path-to-my\file.ocx
InprocServer32 = 8tYCAGak)9S9&~swl.$?MyFeatureName>*&N$B'fk?As1x2J653?'
The only think I can make out from the extra value is the MyFeatureName which is the internal name of the MSI feature that contains the .ocx file. The key is not listed in the Registry table so it must be generated by the Class table.
The problem I'm having only happens in Windows Server 2008. It seems that the app trying to use the COM server is failing to find the path to the .ocx file from the (Default) value and instead it is finding the InprocServer32 value. This results in the app launching the MSI and then having the MSI being stuck in what seems like an infinte loop.
I'm wondering if this is a known issue in Windows Server 2008 or whether there is a way to prevent that extra value from being generated by msiexec.
I'd read this article and see if it helps you get where you want to be:
RobMen's Recommendation: Do not advertise COM information in MSI
You might want to turn off InstallShield's COM Extract at Build and instead do a One-Time COM Extract on the component in question. Then you can go into the Component Advanced section and manually manipulate the registry / com table information to be how you want it to be.
If you use WiX at all, another workflow / trick is to use Heat to build an MSI or MSM around your COM server. Then use InstallShield to edit the MSI/MSM in direct mode and the Registry view to export the Registry Keys/Values to a .REG file. Then import that .REG file into your Component in your real install project.
I can't help you diagnose what's going on, I'll just mumble a bit about what this all means. This is a counter-measure against DLL Hell. It is supposed to protect your application against some kind of other install program that could overwrite your COM server registry keys. Specifically the (Default) key which gives the location to your server DLL.
From the fake InprocServer32 value, the app can auto-detect that the Default key was overwritten and automatically launch MSI again to repair the damage. Which is what you see happening.
I thoroughly dislike the feature, it is just one more fail point in something that is already hard to troubleshoot when it blows up. And it is a useless feature, it assumes that the other installer doesn't use the exact same counter-measure. Which would have worked 10 years ago.
No idea what you'd do to troubleshoot this particular failure. Other then just punt this cr*p and let the servers just SelfReg themselves. At least you'll have something to work with when that doesn't work.