We're working in quite a large project and is having a hard time getting people to configure their Visual Studio correct (tabs instead of spaces etc.). We found a great solution in using the EditorConfig extension for Visual Studio.
However there are still some developers that seems to ignore our request to install this extension to their Visual Studio and hence I'm wondering if there is any way to force an extension to be installed before a solution can be opened, maybe some setting in the .sln file?
No there is no such option built-in. If your machines are domain joined, you could push out the installer through System Center or domain logon scripts.
You could cheat and create a solution level pre-build step. Create a target file named: before.{solutionname.sln}.targets and store it next to your solution file. Check it into source control. In the targets file you can use standard MsBuild to see if the extension is installed (you'll need to check the file system probably) and if not present force the installation by calling vsixinstaller.exe to trigger the install.
Related
I'm working with Visual Studio 2013 professional and Qt 5, so I installed Qt5VSAddin, which is working as intended (I can choose an installed Qt version; meta compiling etc is working; Creating new VS Qt project works like a charm).
However I would like to use the same project and solution files on different machines, where Qt isn't necessarily installed in the same directory.
At the moment, the Qt addin changes the content of the project's .vcxproj.user file and adds the line <QTDIR>directorypath</QTDIR> with "directorypath" being the path I've chosen in QT5->"Qt options"->"Qt versions" of the addin. So if I compile on that machine, QTDIR in the .user is changed to that machine's Qt installation directory, meaning that I'll destroy the project file for anyone else trying to compile the project on another machine (maybe someone without the addin).
What I want to do is to change this Qt version information to a path relative to an environmental variable, like <QTDIR>$(MY_QTDIR)</QTDIR> or <QTDIR>$(MY_DEV_ENVIRONMENT)/Qt/</QTDIR>. Unfortunately, Qt5VSAddin does not allow to create QT versions with environmental variables (at least not with $() syntax) because it does not let you click on the "OK" button in this case.
I tried to change it in the .vcxproj.user file direcly, which does work (I can compile the project this way on another machine without the addin), but on VS2013 restart or clean->build it will overwrite the changes again.
I tried to deactivate the Qt5VSAddin in extras->add-in-manager (unchecked all 3 boxes) but after VS restart, the addin is active again. How can I deactivate it completely without uninstalling (I would still like to create new Qt projects with the addin occasionally)
Is there a way to set the Qt version path of the Qt5VSAddin including an environmental variable?
If not from the GUI, maybe I can change it directly in some config file? unfortunately I couldn't find the file/location where the addin configuration parameters are placed. So where are those pathes and settings saved to?!?
Addin stores its settings and Qt paths in registry: HKCU\Software\Digia\Qt5VS2013\ and HKCU\Software\Digia\Versions\ accordingly.
I didn't find yet where those settings are placed.
I tried to create a fantasy-named-folder and search for that foldername within all files on my drive, but didn't find it...
However I found the reason why I could not deactivate the Qt5 addin in Visual Studio for longer than the current session:
Visual Studio has to be started as Administrator to change the Addin options (at least for the Qt5 Addin) persistently!
After deactivating the addin, everything works as I like it.
I'm still interested in finding and manipulating the Qt-Versions pathes of the addin, since accessing the new project->Qt5 Projects templates, without re-activating the addin, results in a broken/incomplete project. So to get a working new Qt project, atm I have to restart VS as admin, activate the addin and create the project there (followed by manually editing ther .user file and deactivating the addin as admin again)...
UPDATE: Unchecking only the "start" addin option as an admin, I can activate the addin for non-admins on-the-fly to create a new project. I think I will be able to work this way, however I'm still interested in the second question.
I want to attach my own folder name to the "DefaultLocation" during msi installation (using VS 2005). Currently all programs installs at "C:\Program Files (x86)". I want to append some "xyz" path to the installation path during installation. So, once the user clicks next, the path for the installation should be "C:\Program Files (x86)\xyz".
Can anyone tell me how to do this in the windows installer.
The short answer is no, because here is nothing in Visual Studio setup projects to support that. You'd need the ability to change the target directory in the UI sequence after that dialog, that's what's missing.
VS setup projects are limited in their support for all the features of Windows Installer, so migrating to a different tool would be useful if this is the kind of customization you're looking for.
Could anyone tell you how to do this in Windows Installer? Technically yes. You'd need somebody who knows enough about the insides of MSI files generated by VS to design a solution (a custom action based off the Next button?) and change the MSI file manually to do it, and how to repeat that after every build (a post build script), and for you or your company to understand enough to fix it if it stops working. That doesn't seem practical compared to just using a tool that will let you do it. My apologies for the editorial but if VS doesn't support it your choices are limited.
I create a new custom project type using a VSPackage project inheriting of MPF library (http://mpfproj11.codeplex.com/). As a result I obtain a .vsix but I need add this project type using a .msi. I'm using the Visual Studio 2010 Setup projet for it. In my setup project I add the content of the VS Package in the same directory where the .vsix put then, but I think Ineed to put in the registre the new type of project because when I use the setup , the project template does not come out in Visual Studio and when I give double click the file with extension of the type of new project and does not recognize it. When I look the registry after install the vsix, this was one of the things that I found diferent. I add this entries in my setup project but It's not working yet.I'm missing something else?
In the projecttemplatedir is the directory where I put the .dll of the project type, the vsixmifest and pkgdef. The project template is in [User]\Documents\Visual Studio 2013\Templates\ProjectTemplates\[Name of new Project Type]\[projecttemplate.zip]
Best Regards
PS: The project type is for VS 2013 but I'm using the VS 2010 Setup project ;)
OK, so first the "don't"s of doing this:
In general, if you are installing via MSI you shouldn't be doing anything user-specific -- no writing in HKEY_CURRENT_USER, nor writing within their Documents folder, LocalAppData, or Visual Studio folders, etc. If you see yourself writing files or registry keys in either of those places, that should be your hint that there's a better way to do what you're trying to do. For what you've shown so far, this raises more than a few red flags for me.
Second, don't ever go writing keys into 12.0_Config. That part of the hive is nothing more than a cache that's built up from other parts of the registry and on-disk .pkgdef files from extensions. It's rebuilt in any number of senarios, including installing new extensions. Any writes there you should presume will get blown away at any time. If you need to write things there you should either (a) write in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\[version] and run devenv /setup or (2) [preferred] put your keys in a .pkgdef inside your extension which gets merged into 12.0_Config for you automatically.
Now the dos:
You said you already had a .vsix produced by the SDK: you can put project templates in there. You can then register those templates in the .vsixmanifest and those will pull in. That's far easier than mucking around with files in Documents -- that's the user's directory...don't go playing with that.
Once you have a .vsix that does most of what you need, you should simply take the files within that and install the files in a folder within C:\Program Files [(x86)]\Microsoft Visual Studio 12.0\Common7\IDE\Extensions. Even better, you might just want to WiX toolset to build your installer, since it has built-in support for installing extensions. It also has built-in support for invoking the "/setup" process if that's what you need to do as well. Visual Studio Setup projects are no longer supported in newer versions of Visual Studio, so you're better off starting with a technology that isn't already obsolete. WiX is even what we use at Microsoft to do the setup work for Visual Studio itself, so it's definitely up to the task.
Last point: almost everything when it comes to Visual Studio extensibility can be done with a VSIX directly, so presume there's a good way to do something that way before falling back to an MSI. Internally, we can register the entire C# and VB language services with just a VSIX -- they're quite powerful.
I found the answer in this link Registering Project and Item Templates. I set projecttemplatedir entry with
[User]\Documents\Visual Studio 2013\Templates\ProjectTemplates[Name of new Project Type][projecttemplate.zip] that is where i put the project template.
I'm working on a project with Qt using the Visual Studio Addin in VS2010 Professional. Two branches of the project use two different Qt versions (4.8.4 and 5.0.2) so I have both versions of the addin installed (1.1.11 and 1.2.1). I'm also actively developing using at least two computers, both Windows 7, for which I have a networked, roaming user profile. I don't know the specifics of how this user account or network is setup.
Qt is installed in different locations on each system. If I set the correct paths in the Addin on one system (System A), it changes them for the other system (System B) and then complains to me that Qt doesn't exist at that directory when I later log into System B. Is there a way to save the paths to Qt versions on the system, without it affecting the paths on the other system? Or will I have to just deal with changing them each time I change computers?
EDIT:
I from looking through the source for the visual studio add-in, I found that these settings are saved as user registry values. I don't know much about Windows roaming profiles but I'm now assuming that user registry values are copied between computers just as their files are. I don't know if there's any way to move these registry values somewhere else without having to edit and recompile the add-in. I suppose the only other thing I could do is write a startup script to edit these settings upon login.
EDIT: Make sure visual studio on each computer can find the right add-in and the right environment variables on the computer you are using.
http://qt-project.org/wiki/QtVSAddin
In this documentation it talks about where it gets installed to:
"%USERPROFILE%\Documents\Visual Studio 2008\Addins"
So you could manually change the location of the addin, to some local system path.
How to -> Visual Studio Add In Manager
Or you could change the qt path that the Add-in refers to every time you log in, or right before opening visual studio.
Setting a system environment variable from a Windows batch file?
I would use version control to just get the files that you need for the project, and exclude/ignore all the environment specific elements of the project.
One way you could achieve this is:
To install Bazaar. Create a standalone tree of the code on a shared drive or on a location on the harddrive that both users have access to.
Do an initial add of all your source and header files and your qt .pro file.
Checkout or branch the code to user specific folders. In those user specific folders, let Visual Studio create all the user specific, Qt Add-on specific, (etc) files.
Also create a .bzrignore file with files and folders like these listed:
Debug
Release
x64
*.ncb
*.suo
*.user
*.vssscc
*.scc
*.vspscc
*.lnk
*.bak
*.aps
*.pro.user
object_script.*
Makefile
Makefile.Release
Makefile.Debug
Then when you want to try your build for each setup, finish your edits, commit/push your changes on the user that did the edits, and update/pull on the user that wants the changes.
Although the version control may be a little tricky to get started with, it will make project collaboration both scalable, trackable, and very manageable!
And you aren't limited to Bazaar. Check this wiki out if you need ideas.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Another way that you could try to go about doing this, is to have all the source code in some path (either absolute or relatively up from your projects locations), or on the computer, and have the project folders reference those paths in the project folders, but have two separate project folders. This would not be nearly as elegant, but would work.
C:/path/to/vs_proj1
C:/path/to/vs_proj2
C:/path/other/proj/source
And in the properties for vs_proj1, and vs_proj2, in the part about locating source files, have ../other/proj/source to find it relatively, or put the absolute path C:/path/other/proj/source.
Also two other things to be aware of when sharing projects over a drive like this, is that when you are referencing libraries, you may want to store that information in a user specific macro file in Visual Studio and reference the macro in your project settings.
Visual Studio - Where to define custom path macros?
And while I'm here, you may need to #define some things in your program to allow for behavior for one version of Qt that isn't in the other.
So for example, in the source of your program, you might have:
#if QT_VERSION < 0x050000
// some Qt 4.x specific stuff, not in Qt 5
#else
// some Qt 5 specific stuff, not in Qt 4.x
#endif
Hope that helps.
Folks,
I am creating an installer project in Visual Studio. This is done using a project of type "Setup and Deployment".
I lay out the file structure of my final install in the "File System" View of the project.
Now, some of the files I create as part of my install are updated while my application is used. I would like these files to not be removed during an uninstall of my application. Is there any way in Visual Studio to designate a file as "protected from uninstall"?
Thanks for your help.
In the Solution Explorer window, in the Setup project, click the file. Then in the Properties window, set the Permanent property to True.
I'm not sure how to do it in the installer, but any file that you create from the application will be preserved in the event of an uninstall.
If you can stand it, maybe you could create these files as a first-time initialization in your application.
Of course, this can lead to other problems (permissions to create a file), but it might be easier than fighting with the cryptic installer setup.