I was wondering if there is a way to copy ALL my settings from ReSharper (including the StyleCop for ReSharper settings and the keyboard bindings I have set for ReSharper) from one PC to another?
Since the export option within Resharper is only for code styles, you'll need to be a bit craftier for all settings.
From Peter Ritchie's blog...
...the settings are stored in
"%userprofile%\application
data\jetbrains\resharper\v4.0\vs9.0".
There are a couple of xml files in
there that store your settings.
Before you upgrade to the latest
build, just copy those to another
directory.
It's very likely that the format of
these files has changed since the last
build so copying the backups over the
new version could possibly make
Resharper to blow-up. So, use with
caution.
I have Resharper 4.1 so instead of "...\v4.0\vs9.0" it's actually "...\v4.1\vs9.0" (obvious, I know, but worth mentioning).
I'm not sure about StyleCop settings, but this should work for most other settings (keyboard scheme, code completion settings, etc...).
There is a R# settings manager plugin for resharper that stores all of this I think, including stylecop settings
Open Visual Studio
Go to Resharper > Manage Options
Click on Import and Export
Click on Export to File
Tick all check box
Click on OK and save the file to your desired location
To import the settings to other computer, repeat steps 1-3 and then select Import from File. You are done.
Enjoy!
You can Export/Import your ReSharper Code Style or put it on the network and share between multiple computers. To do so:
From VS Menu select ReSharper -> Options then in Option dialog select Languages/Common/Code Style Sharing.
Not sure if it's exactly what you're looking for.
StyleCop settings are not stored in the resharper plugin. they are in the stylecop directory and in an xml file (Settings.StyleCop).
I have a solution that i am using!
Skydrive and junction link magic.
I create a junction in the filesystem that point the settings to a skydrive folder.
this way i have everywhere i use skydrive the same settings!!!
On the target pc i do the opposite.
Hope this helps.
Steve Dignan's answer is probably correct for 2009 version of Resharper.
In newer versions of Resharper global for PC Resharper settings are located in:
%userprofile%\Appdata\Roaming\JetBrains\Shared\vAny\GlobalSettingsStorage.DotSettings.
Solution team-shared settings are in the solution folder called {Solution Name}.sln.DotSettings.
Solution's personal settings are in {Solution Name}.sln.DotSettings.user.
Source: https://resharper-support.jetbrains.com/hc/en-us/articles/115001216530-Where-to-find-DotSettings-files-associated-with-settings-layers
So to transfer settings between 2 PCs, copy settings file(s) for the appropriate layer(s) you want to transfer and that's it. Usually just copying global is enough.
Related
I've read that VS2017 supports .editorConfig and that you can create your own .editorConfig files at solution/project level and share them, however, I am wondering if the machine/user -wide configuration can somehow be shared?
I mean these settings:
Or am I completely wrong in thinking that these settings are related to the new .editorConfig support?
Yes, you can. You should go:
Open a solution in Visual Studio.
Go to "Tools"
Go to "Import and Export Settings"
Choose Export
Follow prompts.
If you follow the export, you'll see that it exports those configuration settings into the script to parse and read when imported into another instance of Visual Studio.
I see how to update the registry manually, by right-clicking on the project, select View, then Registry, but I have alot of registry changes that I need to incorporate into my setup project, and I've already exported each of them to a *.reg file. I don't want to have to go through and add each of them for the setup project manually again.
How can I add my *.reg registry files into the setup project?
As noted in the comment, right-click the "Registry on Target Machine" root node and click Import. It will ask for a .reg file. And will populate the tree with what it found in the .reg file. Just repeat this if you have more than one .reg file.
The Setup project designer doesn't exactly have the most discoverable user interface. It uses right-click context menus a lot and commands are scattered between context menus, regular menus and buttons. So if you are looking for a feature that you think ought to be there then some wishful left and right-clicking on UI widgets can help you get lucky. Spending ten Friday afternoon minutes clicking away is advisable. Note that it was removed from VS2012 and won't come back, it is still available in the gallery.
Just right click the project and add the file to your setup project. Have your application go through the .reg file on first run to make sure the registry is properly set up.
You may add or update your .reg files programatically. Let's say, for example, that you may want to merge a given file.reg to your registry:
Process _re = Process.Start("regedit.exe", "/s file.reg");
_re.WaitForExit();
(Just keep in mind that newer Windows versions use Unicode instead of ANSI when creating/consuming .reg files.)
I used to be able to debug using Visual C# Express 2010 with no problem before. However, since I've opened my project using MonoDevelop (to port it under MacOS), I can't seem to be able to debug anymore.
The exact error message is available below:
A lot of people says to go in the configuration manager, which I'm familiar with, however, I can't seem to find it in the Express version.
Since you didn't have this issue prior to opening in Monodevelop, it more than likely changed something within the solution and/or project files. There are a number of posts on stackoverflow...
stackoverflow: no symbols
stackoverflow: no symbols when crossing module boundries
(From Răzvan Panda comment on the question)
... that talk about missing symbols. However, based on the information provided about monodevelop, I'd venture to guess that the IDE changed something within the solution and/or project files.
If your solution is under source control and you don't see any differences in these files, let me know. Otherwise, you could create a new blank solution/project file (from Visual C# Express 2010) and re-add all your files to it to get the default settings back and see if that resolves your issue.
EDIT: Also, keep in mind that there are ".user" files that I guess "might" have an effect on build/debugging configurations. If re-adding your files to blank solution/project files doesn't work make sure all the "extra" files like ".user" are not in the directory. Usually files like ".csproj.user", and ".suo". I've never had an issue deleting these they store local configuration changes that are not usually checked into source control.
I had same problem with Symbols when I added some dll to my project so what I did was to manually adding them. you can try going to tools > option > Debugging > Symbols and from there you can add the file root (in this case monoDevelop) and it automatically looks for all .pdb files and adds them to your environment. After rebuild it should be Okay.
Cheers
As George Duckett said:
Re. configuration manager, enable expert settings first. Tools->Settings->ExpertSettings. Then find it under Build->ConfigurationManager
Then changed it to Debug.
Someone on our team installed StyleCop and since then all of the projects he loaded up and committed to source control refuse to load unless stylecop is installed.
I know I can manually edit the .csproj files to get rid of it, but is there an easy way to automatically remove these stylecop parts from the project files so they can be loaded and built on a non-stylecop-infected Visual Studio machine?
Why remove it?
In my opinion using StyleCop is a good thing.
Your only problem seems to be that your team member didn't set up StyleCop properly.
From your description, I guess that he wanted to set up StyleCop with MSBuild integration:
http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/24/source-analysis-msbuild-integration.aspx
He apparently just left out the last paragraph "Team Development": copy the StyleCop files into your project and check them into source control, so you don't need to install StyleCop on every single developer machine. (see my link for a more detailed description)
If you do this, StyleCop should work on every machine, no matter if it's installed or not.
We are using StyleCop in this way as well, and I think it's the easiest way to use it.
I just had to insert two lines into each .csproj file and check a few files into source control once...and StyleCop just works, on every compile, on every machine (no matter if it's on a developer machine or the build server).
Stylecop hides real warnings. Its a vanity exercise and its evil.
Do not use it.
I find that stylecop generates many many trivial warnings that drown out the real warnings. By all means use these tools but don't force them to be on. Having no stylecop warnings is a meaningless metric.
I disabled StyleCop by adding the following GlobalSettings configuration to the file settings.stylecop in the solution root.
<StyleCopSettings Version="4.3">
<GlobalSettings>
<BooleanProperty Name="RulesEnabledByDefault">False</BooleanProperty>
</GlobalSettings>
...
</StyleCopSettings>
TEST DRIVEN DEVELOPMENT
Red -> Green -> Refactor
TEST DRIVEN DEVELOPMENT (WITH STYLECOP)
Red -> Red -> WTF? -> Red -> Red -> ...
Also, from here:
Bob: Using pattern matching, the software identifies ugly code
Charlie: —and fixes it!
Bob: No. It prints a message about each transgression.
Charlie: And then the user right-clicks to fix them all?
Bob: No. The message scolds them 'invalid spacing around the comma'.
Charlie: And then explains how the user can fix it?
Bob: No, that information is in a separate document.
Charlie: On Google?
Bob: No.
This is why don't use Stylecop.
It seems like this setting should be stored in the solution file so it's shared across all users and part of source code control. Since we don't check in the suo file, each user has to set this separately which seems strange.
It is absolutely necessary that everyone can define their StartUp Project themselves, as Jon has already said. But to have a dedicated default one would be great, and as I can tell, it is possible!
If you don’t have a .suo file in your solution directory, Visual Studio picks the first project in your .sln file as the default startup project.
Close your Visual Studio and open the .sln file in your favorite text editor. Starting in line 4, you see all your projects encapsulated in Project – EndProject lines.
Cut and paste the desired default startup project to the top position.
Delete your .suo file.
Open your solution in Visual Studio. Ta daa!
In most cases, it does make sense to have a default on this.
It would be much better to accommodate a default startup project and store this in the .sln file, but which can be overridden by a developer in their .suo file. If the startup setting isn’t found in the .suo file, the default startup project in the .sln would be used.
Actually, this has been suggested on Visual Studio’s UserVoice.
Why should it be a non-user-specific preference?
If I've got a solution with 10 files in, and one developer is primarily testing/using one of those tools, why should that affect what I start up?
I think MS made the right choice on this one. The project I want to start is far from necessarily the project that other developers want to start.
I wrote a little command line utility for Windows called slnStartupProject to set the Startup Project automatically:
slnStartupProject slnFilename projectName
I personally use it to set the startup project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on GitHub. Forks and feedback are welcome.
If you are using GIT, you can commit the default SUO file and then mark it as unchanged using
git update-index --assume-unchanged YourSolution.suo
It works also if you want to have more than one project in your default start group. The only disadvantage that I know about is that this command must be run by everyone who don't want to commit the SUO file.