I've recently installed resharper 6.0. It took my long time to set up everything as I wanted. Now I want to export all this settings to another computer. I've tried this aproach without any success (might be because the computers use different versions of visual studio?). Then I found this in this answer. But RSM works for r# 5. I started reading to see if there is going to be RSM for r# 6.0 and there will not be because in r# 6.1 some settings management options are included. But I'm stick with r# 6.0.. Is there any way I can transfer my settings from one PC to another?
Now you may want to update to ReSharper 6.1 where the management of settings are improved including an export and import feature.
You didn't explain what you meant by "without any success".
Were you able to find the folders and copy the files?
Were there files already in the target directory? (If there weren't, you probably had the wrong directory.)
Did you diff the old and new files as a sanity check? (This would be especially important since you're apparently expecting this to work even when the two machines aren't running the same version of Visual Studio. There could easily be differences in the file format across VS versions.)
Did you make sure to close Visual Studio before copying the files?
Did you just copy files in ReSharperVersion\VisualStudioVersion, or did you also copy the files in the vAny directory?
At any rate, if you really can't copy the global settings files, and if you can't install 6.1 (why not? it's a free upgrade from 6.0), I think your only other option is to export and import your coding-style settings by going to ReSharper > Options > Languages > Common > Code Style Sharing. That won't get all the ReSharper settings, but it will get some of the most important ones.
Related
I am learning C and I want to install MinGW on my laptop. The MinGW installer is a web-installer, it requires the computer to have access to the internet when installing. But the problem is that my computer's not connected to the internet. So it can't be installed.
So I am thinking of downloading the complete offline installer on my smart-phone and transfering it to my PC through blue-tooth.
I have already tried TDM-GCC, but even that requires me to download somthing.
So is there an offline installer to MinGW? If yes where can I get it?
I did not find an offline installer for MinGW,but instead I found a better Windows port; which is MinGW-W64
From http://mingw-w64.yaxm.org/doku.php:
Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution.
Now to answer this question: it has to be mannually installed by downloading the zip file. It won't require additional download.
You can download it from link : https://github.com/jonasstrandstedt/MinGW
You need to extract the MinGW folder in C:\ eg: c:\MinGW . Then what you need to follow the steps given in the link above. In CodeBlock IDE go to settings>compiler>Tochain Executables. There you need to click on auto detect or specify the folder manually.
The most direct answer to the question "Is there an offline MinGW installer?" is "maybe, but it would be a snapshot from the past, and it's almost certainly not up-to-date with the latest available released versions." The individual packages are made available (almost) as soon as they're released, so capturing everything in a self-contained installer is a moving target.
But, you can use the standard installer offline with a bit of prep work if you use MSYS2's pacman, which manages dependencies and grabs all the right versions for you.
The details are given in an answer to another question (https://stackoverflow.com/a/46791235/).
I would like to setup an automatic software distribution process, preferably from Microsoft Visual Studio, which builds my projects in all the different configurations and platforms, and packages all the created objects in a predefined folder tree structure.
The software distribution packages would be for Windows libraries and WDM driver projects written in C/C++. Each library has several different configurations (i.e. Windows 7 Release, Windows XP Release, MT/MD runtime compilation flags) for different platforms (i.e. x86 and x64). A similar thing is with the drivers. Without any automatic process to create a software distribution package, it's necessary to build all the different configurations for each platform and then copy the created objects to a predefined folder structure and then zip the created folder giving it a release name and version. This process is quite time consuming and error prone. Therefore, my goal is to automate this process using a clean a nice solution.
I've been researching about this for a few weeks already and have actually implemented a few different solutions. However non of the solutions I implemented until now is flawless whatsoever. Hence since this should be a problem that I guess many developers have already encountered, I would like to hear different opinions on what would be a nice and efficient way to do it.
Up until now I've tried the following:
A batch script and a Makefile to be used by NMAKE. This is not so good because it makes difficult to set the same build parameters that are set on the visual studio project.
Implemented a "deploy" target task (editing the .vcsproj files) which calls MSBuild of the project for each configuration/platform and copies the generated files to a distribution directory. This has the advantage that I can start the deploy activity from within visual studio but it also produces several environment variables problems, specially when building windows drivers.
Any ideas or suggested solutions will be appreciated.
Thanks in advance.
Zion
If you haven't already, add a post-build step for each lib and driver which copies the built files into your specific tree and also zips them.
If you haven't already, create one Visual Studio solution (.sln file) which builds all these projects at once.
If you haven't already, set up Build configuration using the Build | Configuration Manager dialog. Now from the IDE, you should be able to specify a specific configuration and do a Build | Rebuild Solution and make sure all the projects are successfully built.
From the command-line, you can now automate #3 by opening a Visual Studio command line prompt (which sets up the environment variables appropriately). Start devenv.exe with appropriate command-line parameters.
I have reinstalled my computer with Windows 7, and Eclipse 3.5.1 (Galileo).
The weird thing is that I can not see any files that Eclipse produces.
I can not find the workspace, can not find the files from the SVN after check out.
It seems like Windows 7 can not read the files produced by Eclipse ... wierd
What could be the reason for this?
Where do you have Eclipse installed? Where is your workspace?
In Windows 7 (Vista, actually), a lot of security policies that existed only on paper in earlier versions of Windows, are now actually enforced by the operating system. For example, according to Microsoft's documentation, it has been pretty much illegal to write to C:\Program Files for decades now, but if you actually tried it, it still worked. Not anymore. As of Vista, C:\Program Files is off-limits.
However, in order not to break existing (broken) applications, Microsoft introduced filesystem virtualization. If an application tries to write to C:\Program Files, it gets silently redirected to C:\Users\%Username%\AppData\Local\VirtualStore\Program Files. So, this specific application sees all the files it created or changed in C:\Program Files, but other applications, and this includes the Explorer, see only the unchanged / empty directory.
This does not just apply to C:\Program Files but also to other system directories as well. Also, it applies to system parts of the registry, like HKEY_LOCAL_MACHINE for example.
In order to sidestep all of this, I simply installed my copy of Eclipse in %LocalAppData%\eclipse (that's C:\Users\%Username%\AppData\Local\eclipse) and created my workspace in %AppData%\eclipse (that's C:\Users\%Username%\AppData\Roaming\eclipse). That Just Works™.
You can launch eclipse with the -showlocation option, which will display the path of the workspace in the title bar.
(See this eclipse.ini for instance)
From there, you can check if you find that workspace, and its eclipse projects within it.
You can also configure your shortcut:
Suppose you have some source code that comes from the unix world. This source consists of a few files which will create a library and a lot of small .c files (say 20 or so) that are compiled into command-line tools, each with their own main() function, that will use the library.
On unixy systems you can use a makefile to do this easily but the most naive transformation to the windows / Visual Studio world involves making a separate project for each tool which, although it works, is a lot of work to set up and synchronize and more difficult to navigate at both the filesystem and project/solution level. I've thought about using different configurations where all but one .c file are excluded from the build but that would make building all the tools at once impossible.
Is there a nice way of building all the tools from a single "thing" (project, msbuild file, etc.)?
I'm really not interested in using cygwin's gcc/mingw or NAnt. I'd like to stick with the standard Windows toolchain as much as possible.
You don't HAVE to use visual studio to compile code. You can make your own batch file or Powershell script that simply calls the compiler on your source, just like a makefile.
So I've been looking into this for a while now and the solutions all leave much to be desired.
You can...
Create a lot of small projects by hand.
Use MSBuild and deal with its steep learning curve.
Use a build tool that does not integrate well with Visual Studio, like GNU make.
You can't even make a project template like you can with .NET projects! Well, you can make a wizard if you want to wade through the docs on doing that I suppose. Personally, I have decided to go with the "many small projects" solution and just deal with it. It turns out it can be less horrible than I had thought, though it still sucks. Here's what I did in Visual Studio 2008:
Create your first Win32 command line tool project, get all your settings down for all platforms and make sure it works under all circumstances. This is going to be your "template" so you don't want to edit it after you've made 20 copies.
(optional) I set up my paths in the visual studio project files so that everything is built in the project directory, then I have a post-build step copy just the dll/exe/pdb files I need to $(SolutionDir)$(OutDir). That way you can jump into a single directory to test all your tools and/or wrap them up for a binary distribution. VS2008 seems to be insane and drops output folders all over the place, with the default locations of Win32 and x64 output differing. Spending a few minutes to ensure that all platforms are consistent will pay off later.
Clean up your template. Get rid of any user settings files and compiler output.
Copy and paste your project as many times as you need. One project per tool.
Rename each copied project folder and project file to a new tool name. Open up the project file in a text editor like Notepad++. If you have a simple, 1-file project you'll need to change the project name at two places at the beginning of the file and the source code file name(s) at the end of the file. You shouldn't need to touch the configuration stuff in the middle.
You will also need to change the GUID for the project. Pop open guidgen.exe (in the SDK bin directory) and use the last radio button setting. Copy and paste a new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file near the source code. Do NOT change them as they are the GUIDs from the dependencies and have to match!
Go into Visual Studio, open up your main solution and add your tool projects.
Go into the configuration manager and make sure that everything is correct for all supported platforms, then test your build.
It's not beautiful, but it works and it's very much worth the setup time to be able to control your builds from the GUI. Hopefully VS2010 will be better about this, but I'm not too hopeful. It looks like MS is giving a lot more love to the .NET community than the C/C++ community these days.
If you have a makefile you can use a 'makefile' project in Visual Studio (which in misnamed - it simply allows you to specify custom build/debug commands), and use it to invoke GNU make.
You will need to change the makefile to use the VC++ command line tools instead of cc or gcc or whatever it uses, but often these are specified by macros at the top of the makefile.
If the makefile uses other Unix specific commands (such as rm), you may need to make modifications, or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 to make it work.
If the build is very complex or involves configure scripts, then you have a harder task. You could generate the makefile from a configure script using MSYS/MinGW, and then modify it as above to make it work with VC++.
Makefile projects will not be as tightly integrated in Visual Studio however. All the build management is down to you and the makefile.
If you're really using Visual Studio, I would suggest creating a project for each tool, and adding these projects to a single solution. From Visual Studio, it's easy to build a complete solution all at once, and MSBuild knows how to build .sln files as well.
msbuild myslnfile.sln
or even:
msbuild
... will build your solution.
Whenever I start a new project, I have to go through setting up the debugger with Eclipse time and time again before I can use it. Isn't there a default setting for all new C projects I can change?
I'm not sure exactly what you mean by "setting up the debugger" (perhaps you can clarify), but under "Preferences -> Run/Debug -> Launching -> Default Launchers" you should be able to select your preferred launcher for different kind of launch modes. This can also be selected individually for each launch configuration.
Typically it is up to the toolchain and/or project to determine which debugger/launcher is suitable to use for that specific project, but I know there is a bug in CDT which prevents toolchains from properly specifying the default launcher to use.
I only use Eclipse for Java, so I can't give you an authoritative answer. But since no one else seems to be answering:
Java projects have a (more or less) hidden file in the project directory called .project and another one called .settings . I'm not sure if this would apply to the C environment as well, but it seems likely. You may want to look at the set of such "hidden" files for a well set up project and a virginal project side by side to find out which settings make the difference.
Given that information, you may be able to simply edit (perhaps with some assistance from a script you can write yourself) the file(s) in question to do the configuration textually without a lot of mouse clicking.