I'm bootstrapping a ClickOnce setup file so that I can add custom actions pre and post install. The only problem I'm facing is that the ClickOnce installation writes to the Add/Remove Programs section of Control Panel. This mean that the user would end up with two uninstallers (ClickOnce and my bootstrapper). I would like the program to be available offline, which rules out setting the ClickOnce deployment to online-only and suppressing the Add/Remove entry that way. Is there any other way to prevent a ClickOnce deploy from adding an entry to the Add/Remove section? Or is there a way to retrospectively remove the entry safely?
its stored in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Just delete the corresponding key and your good but it does sound a little malicious
http://support.microsoft.com/kb/314481
Related
The new version of VSCode 1.75 contains the new function Profiles, which I was waiting for.
It looks like you can install, activate or deactivate extensions in each profile, without affecting the other profiles.
So far I only managed to install, activate or deactivate extensions via the extension manager, or via the view page of the respective extension.
There is this new view that can be displayed via [Settings-Wheel]-[profiles]-[show contents]
There you can find a checkbox for each extension.
Intuitively, one would assume that the extensions for a profile can be either completely switched on or off (install) or at least activated / deactivated.
For me this checkbox has none of the mentioned effects.
The profiles work nevertheless, as said, with an activated profile extensions can be installed and uninstalled, the profiles can then be switched, and a profiles extension states get properly restored when reselected.
However, the view with these checkboxes seems largely pointless to me at the moment.
So my question is: what is their purpose?
Should their purpose be what I suspected, and the feature just isn't "ready" yet?
The checkboxes are for exporting the profile without including undesired configuration options. For example, the "UI State" option will save the currently open menus and submenus as a part of the profile's configuration, which you likely don't really want in most cases.
Notably, when I created a new blank profile and accessed this menu the only field present was the UI State, which implies that if a field is the same as the default configuration it won't be saved to the file.
When you export, you can name the profile and either save it locally as a ".code-profile" file, or upload it directly to GitHub as a gist. The file uses a syntax that I believe is unique, though it's very possible I just don't know it. It would be nice to have a simple JSON schema, but I'm sure the community is going to automate the hell out of this process within a few weeks/days.
I'm pretty sure the purpose of those checkboxes is to select whether or not each extension gets exported as part of the profile. Presumably they are all activated upon importing the profile and installing those profile extensions.
I want to keep the all the file structure of extension when we uninstall any extension from the site.
In the uninstall process I want to remove DB tables only and want to keep all Files/Folders.
Can you please guide me if there is any solution.
Thanks
The manifest file for the extension includes a list of the relevant files that are installed for the extension. These can be copied from the website and zipped to recreate the install file for the extension.
Some extensions may also create associated data which you can back up by exporting relevant database tables and/or files (e.g. in the media or images folders).
A normal uninstall process (via Joomla! manage form) removes everything unless the extension has bug in its uninstall schedule. So, if you need to keep the files, uninstalling the extension won't be a good idea. I suggest you drop tables via phpMyAdmin instead.
To do that, go to your web hosting control panel (cPanel, DirectAdmin etc.) and look for the link to phpMyAdmin. Then select the database that contains your website data (if you got multiple databases and are not sure which one is the right one, you can check it via Joomla! admin > Global Configuration). When you found the database in phpMyAdmin, click on its name to go to its tables. Then select the table(s) of that specific extension by checking the checkbox(es) beside them. Then at the bottom of the all tables click "Drop". In the popup window click "OK" and the table(s) will be removed without effecting your folders/files.
I suggest you get a backup of your whole website first, if you're new to phpMyAdmin.
Be careful!
My media file contains three folders, of which, I want to have only one of those to be installed on user’s machine based on his selection.
One quick and dirty fix for this is to install all the three folders onto the user machine and then delete two of the unwanted ones. This is additional work and users might not like this. Is there a better way?
That's what installation components are for. You can select them programmatically like this:
context.getInstallationComponentById("123").setSelected(true)
You can configure installation components on the Files->Installation components step.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.