How to remove IIS management Machinekey validation key and decryption key - windows

Hello i was seaching around for some time on how i remove from the IIS the validation key and the decryption key. as in the UI i cant see how i remove it.

Because it is only possible to choose from two options,
Let ASP.NET runtime automatically generate the key(s) at runtime. (aka, leave the check box checked)
Pre-generate the key(s) and hard code them. (aka, leave the check box unchecked)
and the management UI clearly presents both options to you and expects you to only flip the check boxes. There is no possibility to "remove" anything from there.

Related

Using Instal Shield how can one install an applcaition(file transfer,prerequiste) through custom dialog checkbox

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.

Using Google Chrome Frame as a "closed container" with HandleTopLevelRequests

Can anyone explain what using GCF as a "closed container" actually means?
I understand from this link that you enable this mode of operation using the HandleTopLevelRequests registry key.
I actually stumbled onto this setting as a way to prevent the Developer Tools window from automatically closing upon postbacks/redirects. That default behavior really makes the Network tab almost useless. :(
By setting the HandleTopLevelRequests registry key as described in the link above, the Developer Tools window remains open like I want.
I just don't know if this is a setting I should leave in place because I don't really understand what it's doing.
Or I suppose another way to ask it is, why wouldn't you want the HandleTopLevelRequests setting in place?
**Another registry key named UseChromeNetworking seems to often be used in conjunction with HandleTopLevelRequests. Bonus points for any details on it as well. :)
Any info at all would be appreciated-

Excel Range.Find and maintaining user selected find options

When automating excel using the Excel Interop API, I can easily do a range search using the method Range.Find. I am passing through the LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase options for the Find. This as noted by the MSDN documentation, persists the values passed into this method into the user settings, so the next time that the user opens the find form, the options will be selected which I used in the Range.Find method.
I need to persist the values of the find options before and after I do the programmatic find. So I want to capture the current find options, then do the Range.Find, and then set the find options back to the options that were set before my search. However, I do not see that the find options are publicly accessible. Any ideas on how to get these?
I'm basically looking to retrieve current find option values for LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase.
Update
The most interesting thing I could find so far is that you can access the Excel Application dialogs - Dialogs Interface. So here, I can get access to the FormulaFind dialog, which is slightly different than the Find and Replace dialog, though may lead to some of the properties I'm looking for. I haven't had any luck, but perhaps there's a way to access the properties through this form using reflection. I'll keep trying something with this.
// xlDialogFormulaFind, xlDialogFormulaReplace
Excel.Dialog dialog = this.Application.Dialogs.Item[Excel.XlBuiltInDialog.xlDialogFormulaFind];
Well, I am not sure if you'd consider this approach, but I'll give a shot here in case it might be helpful.
What I would do is, I'd create a registry key holding the values you wanted to persist. I could then call RegistryKey.GetValue(valuename) to retrieve values, provided that there's no exceptions thrown.
As long as that registry key stays there, unchanged, and you have enough privilege to access registry key, you should be able to always get the same values.
Wish we could really use application settings here, which would make it easier, but, well, as you might have known, vsto add-in doesn't like it, according to this article.
You cannot use application settings in an unmanaged application that
hosts the .NET Framework. Settings will not work in such environments
as Visual Studio add-ins, C++ for Microsoft Office, control hosting in
Internet Explorer, or Microsoft Outlook add-ins and projects.
Hope this helps.

Remove registry key during uninstall

I have a simple C# application that allows users to specify that it should be (or should not be) started with Windows; it does so by setting (or deleting) a registry key (namely, ...\Software\Microsoft\CurrentVersion\Run\MyApplicationHere).
I am using a VS setup project to create the installer for this program. I don't want the installer to create this key; it should only be created when the user selects the option from within the program.
Here is the issue: I would like the uninstaller to delete this key if it exists, preferably without resorting to any sort of hackery; if there is a simple "built-in" solution I would love to hear it. Thanks!
just right Click on Setup then Select View -> Registry, you can add a
registry key to the list. The key has properties (right click ->
Properties) AlwaysCreate,DeleteAtUninstall and Transitive keep
AlwaysCreate to false, and DeleteAtUninstall to true and Transitive to
true as well
adn its Done..
The Registry table is designed for this:
http://msdn.microsoft.com/en-us/library/aa371168(VS.85).aspx
See especially under the description of "Name":
If the Value column is Null, then the strings shown in the following table in the Name column have special significance.
- The key is to be deleted, if present, with all of its values and subkeys, when the component is uninstalled.
Try creating a custom uninstall action to remove the key. Not very "built in", but it's only a couple of lines of code.

VS 2008 MSI Installer: Context.Parameters["TARGETSITE"] empty when repairing

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...

Resources