I have a C# application in Visual Studio 2010 that uses several application settings. For one of these, I want its default value to be conditional, depending on whether the C# application is running as 32-bit or 64-bit. That way, if the user manually assigns the setting a value, it'll be persisted, but otherwise we choose an appropriate value on the user's behalf.
It's clear that I can set a value of the setting's type in the Value data grid cell. But is there a way to use a conditional so the default value is chosen based on specific logic?
Related
Unfortunately, I have the problem with setting condition for Registry value in Visual Studio Installer project.
The main goal is to suppress updating value for application registry key for application updating.Installer should not do anything for the value if it is already in application registry key.
In value properties, I see two significant:
Condition
Transitive, set as True
It seems that for condition the most suitable is:
NOT [HKLM\Software\Company\PasswordReset]{callSignInstance}
Where key is [HKLM\Software\Company\PasswordReset] and name of the value is callSignInstance.
But in this case value just disappears from registry key. What is correct condition should be for this case?
Best regards,
Oleh
I am trying to install three application by creating custom dialog .Within Custom dialog there are checkbox and Onclicking checkbox and thereafter doing next I want my application to do file transfer ,install the prerequiste based on which checkbox is checked .I want this to happen for all the three application.Please suggest how to do it and how can we give the condition to do so.
Assuming you're talking about a custom dialog for a Basic MSI, I would suggest the following:
Ensure each application in question is part of a separate feature. If you go with the original dialog set, this would potentially let the user select them by feature name, or you could hide them. These features should have meaningful names, along the lines of App1, App2, App3.
Ensure your three check boxes are associated with different properties, such as INSTALL_APP_1, INSTALL_APP_2, INSTALL_APP_3. I show public properties here out of habit, but since they will be used in the same sequence (on the same dialog box, even), it's okay to use private properties. And use suffixes more meaningful than 1, 2, 3.
Adding multiple control events to the Next or Install button on the dialog box you described. For each feature you want to control this way:
Add an AddLocal control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is checked (i.e. with a condition like INSTALL_APP_1
Add a Remove control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is not checked (i.e. with a condition like NOT INSTALL_APP_1.
If you are going to show this dialog box during maintenance, you should also initialize the values of the check box properties (INSTALL_APP_1, etc.) so that merely going past this dialog box doesn't change their installation state. You can use feature-state condition syntax (!App1, etc.) to do so in SetProperty custom actions scheduled just before showing the maintenance dialog (e.g. set property INSTALL_APP_1 to the value 1 with condition !App1=3).
If these features are shown in a feature selection control, be sure to update the properties accordingly. Do so on the Next button of that dialog using a combination of the feature state and feature action syntaxes. The property should be 1 if the feature is currently installed and not being removed, or is being installed; it should be set to empty ({}) otherwise.
This is a lot of steps, but together they help ensure the features will act as a user expects. If he does nothing to change their state, they should persist as previously set. If visible in both the feature selection control and via check boxes, they should act in sync.
As far as prerequisites, if you mean the InstallShield concept of prerequisites, this you can associate prerequisites with the features for those apps. If you just mean other components inside your MSI, those work perfectly well with the features defined in step 1 as well.
In Visual Studio 2010 (Ultimate), is it possible to step through some code, and, if a variable is not correct (e.g. you want to get all records beginning with 'A' but there is none, so you want to try 'B' instead), is it possible to change the code while in debug mode, to do this (change variables while in debug mode)?
It is quite annoying to have to stop debugging, change a value, then debug again and see the result. It'd be much easier to do it all in debug mode, anyway.
Thanks
In the watch window just enter the statement you want executed. For example if you want to set the variable prefix to "B" then just type prefix = "B" and hit enter.
You may also change code while running, however there are a number of limitations to this feature. See Microsoft's Edit and Continue documentation for details: http://msdn.microsoft.com/en-us/library/bcew296c(v=vs.80).aspx.
In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This works for me.
c
In other words, can I count on a control ID as a reliable identifier?
From some reading I've done, it sounds like .NET controls can have control IDs that change with every run, is this so for Win32 apps as well, or are they something that's hardcoded in the source?
The window/control in question is actually an Internet Explorer dialog if that helps.
In general win32 dialog resource IDs do not change when you run the app. However, they are internal implementation details and as such they are subject to change whenever an update (patch, service pack, major release) to the application is made.
In general all of IE's dialogs use hard-coded control IDs. There may be some that are dynamic. If you give the specific control I might be able to give you a better answer.
The answer is "it depends on the circumstances, but in the majority of programs, these will not change across multiple executions." In general, a control ID or resource ID will be the same across every execution of the same program.
In most implementations, resources are stored in the resource section of the PE executable and are assigned a resource ID within that data structure. Usually, the developer specifies the resource in a .rc file.
The exceptional case is via APIs such as CreateDialogIndirect() which allow IDs specified through the API at runtime. Such dynamic creation is uncommon, however. Consistency of resource IDs and control IDs is the expected condition, so even in the case of the CreateXXXIndirect() API, users of the API would be ill-advised to chose a varying ID.
Microsoft has spent years trying to deal with applications which embed assumptions about internal windows implementation details. One of the biggest causes of compatibility problems for IE8 was caused by applications which made assumptions about the window order of IE controls. When the UI was changed in IE8, the controls moved and a number of browser plugins broke hideously.
In general you should never ever make assumptions about controls in an application that you didn't write - your code WILL break in the future (not might break, will break).
As a general rule, no they don't change between runs. Control IDs are usually specified with a dialog template, and that's a static resource compiled into an .exe or .dll. Controls can also be created using a regular call to CreateWindow or CreateWindowEx. In such cases, the ID is usually a constant, but it could be anything in principal (even a random value).
In any case, if you're planning to muck around with a dialog in another application, then you are asking for trouble. Control IDs can and do change between different versions of a program.
It depends on the control. Controls that are dynamically created could have a different ID every time they are created. Controls based on static dialog resources will have static IDs.
Even if a dialog is backed by a dialog resource template, controls can be added dynamically at runtime and those controls could have dynamically generated IDs.
Depending on your intent, it may be acceptable to store and reuse it for future lookups or traces; but in general it isn't safe.
If the window is based upon a dialog template, items declared in the template generally don't change. It is perfectly safe under typical circumstances to use these as identifiers.
Sometimes the window class name or a portion of it can be used as an identifier instead, depending on the window host.
If the dialog is one of the standard prompts from internet explorer, you may want to use text stored in adjacent controls or the dialog caption as additional verification info (if localized versions of IE are not an issue). If the dialog is a window that embeds an instance of MSHTML/IE; none of these options may be viable- but you can use OLE accessibility to get at the document shown and then browse the DOM from there.
i created a web setup project in vs 2008 and added some custom actions.
While installing i get the default forms (apppool, appname, website), some pre-defined custom forms and some selfmade custom forms.
Now while installation i add some data in the registry.
I have only one problem: TARGETSITE property.
This property is filled by default form (Context.Parameters["TargetSite"] is something like "/LM/W3SVC/1" for defaultWebSite) and its value properly added to the registry.
Everthing is fine until i use the repair function...
Whilst repairing, the first few default forms will be skipped by installation, therefore the TARGETSITE property will be empty (Context.Parameters["Targetsite"] is "").
Sadly i can not interfere with that to get the needed value from registry where i added it for exactly that reason.
Because the registry values will be updated before custom code is triggered in the "override Install" method.
Even onBeforeInstall is fired after the registry has been updated.
If a rollback is done, while repairing, the registry key will be reset to the correct value before, so i have to believe, that somehow i can access this value from within my custom action code.
Someone has any suggestion on how to get this important value?
P.S.:
i tried to set the condition within the registrykey, so that it would only be updated when the TARGETSITE value is not empty, but i´m afraid this will be ignored big time...
TARGETSITE != "" in the registry keys condition-field has absolutely no efect whatsoever...
I solved the problem by working around the installers registry key.
I manually create a subKey under the installers registryEntry, where I store my Context.Parameters["TARGETSITE"] value.
So the repair feature will not overwrite the keyValue because it´s a custom key.
Now I have my value either in the context or in the registry.
FunFacts:
When I create the customKey within the Installers own key, I take advantage of the standart meachnism, which delets the installers registry key and with that my customKey will also vanish.
Maybe this might help if someone else faces this problem sometime...