I have issue with both "Go to definition" functionality on Visual Studio and "Go to Implementation" for Visual Assist plugin.
As I know, to perform jump to code I need to add additional include/source paths to the project property for MVS or sources paths for VAssist.
I have added them, but nothing changed. When I press go to definition I have following message:
Is recursive parsing of include path that was added to additional paths?
Or I need to add all paths separately to that need for? If so, what to do with a very big number of paths within include/sources files?
Thanks.
I found solution for my own question. Seems like MS VS bug.
To enable proper jump, just need to turn of "Colorize inactive code blocks in a different color" check-box:
Related
We have a web project with Angular, jquery and Telerik Kendo.
When searching for any text Ctrl+Shift+F that is then found in any of their *.min.js or *.js.map files, the VS (both 2013 and now 2015) will become unresponsive for 30-60s. Also when later I scroll the Find Result 1 window, it will momentarily become unresponsive when long line becomes visible. Everything becomes smooth again if I clear the search results from Find Result 1.
We have the *.min.js and *.js.map files included in project itself. Is this wrong approach?
This is a well known problem, the Connect feedback article is here. These files are poison pills to an IDE, compare to this Q+A.
Little to add, beyond not adding them to your project, the proposed workaround in the article is the obvious one. And as long as you need to search through these files you surely want to work with the non-minimized versions of them.
In the Find options, expand "Result options" (Alt+S) and enable "Display file names only". The contents of the files will not be displayed in the find results and everything will be a lot faster. You can still double click a file name in the find results to go to the exact location of the match in that file.
Does this problem happen for everyone, or only on particular machines? Are there any Visual Studio extensions that may be slowing down the search? You could try and temporarily disable all extensions and see if you have the same problem.
Otherwise, I would agree that including the .min.js and .map files in the solution / project is not ideal anyway.
My recommendation is to use Bower to manage your 3rd party client-side library dependencies. They say use the right tool for the job, and in this case, it's currently Bower.
Bower support is baked in to Visual Studio 2015. Here's some Microsoft docs on using Bower in Visual Studio 2015:
http://docs.asp.net/en/latest/client-side/bower.html
Docs for installing Kendo using Bower: http://docs.telerik.com/kendo-ui/install/bower
Now, this by default will put those vendor libraries in a bower_components folder under the project root. You would then not include this folder in your project, or in source control (but bower.json and optional .bowerrc would go into source control).
This should alleviate your problem in VS2013, but in 2015, Find in Files will still search bower_components. So your best bet is to try and narrow down the source of the slow-down.
Using Bower potentially impacts your development and build process, so you might want to avoid that if that's going to force your hand to make other changes you're not positioned for yet.
One thing you can check to try and help solve this issues, is in your gruntfile's minify task, make sure the mangle property is set to false. Mangle changes the variable names to really short names, so sometimes that can mess up your other files that use variables from those minified files, and other errors can occur. I'm not sure why visual studio crashes or wouldn't be able to handle searching for a string that doesn't exist, but it's something to consider.
I have a solution with many many projects, I did not write this project but it's an open source project (mysql++) , I need to include an include path to all projects. I would like to just globally add this include path to the solution and have it cascade down to all the projects... is this possible? I dread thinking about having to do the same thing for each individual project.
Thank you,
Alessandro Ferrucci
Visual Studio lets you modify many projects at once. Simply click the first in the Solution Explorer, shift-click the last, and right-click the group to get to the project properties. Now any changes you make affect all projects you selected.
Don't do this if individual projects have different include path settings and they must continue to have different settings. Changing the include path in this way will make them all the same. This may be fine even if they currently have different settings if you can agree on a path that makes sense for all the projects.
If each project has to have a different include path, the best way I know to do what you want is to open all the project files in a plain text editor, search for AdditionalIncludeDirectories, and paste the MySQL++ include directory plus a semicolon into the string that follows. Be sure to do this for all places that attribute appears in each project. At minimum, there will be two: one each for Release and Debug builds.
EDIT: If you use a good text editor, this can be a lot faster than doing the same operation inside Visual Studio. I recommend Vim, if you already have vi skills. Its . command to repeat the previous edit makes the "search, navigate, change" cycle much faster.
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.
I've got a solution containing multiple projects. I'm only changing the code in one of them, but every time I hit Ctrl+Shift+B, Visual Studio rebuilds all of the others.
I want it to build the other projects, so this is good. What's not good is that, normally, it would see that there was nothing to do. I have a wonky dependency somewhere, so this isn't working.
Is there a tool or macro (or switch) that'll explore the dependency tree and tell me which files are missing or out-of-date, so that I can get it to stop?
I know that I can solve this specific case, by (e.g.) touching all of the project files.
Unfortunately, I've often seen this situation when a file is configured to produce an output file (e.g. an IDL file is configured to output a typelibrary, but doesn't contain a 'library' block, so it'll never create a TLB).
This wouldn't be resolved by touching all of the project files, so I'm looking for something more general to add to my personal toolbox that'll easily tell me why a file is being rebuilt, whether it be because it's older than a dependency, or because the project is misconfigured to expect an output file that will never be produced.
In Options / Projects and Solutions / Build and Run turn up the MSBuild project build output verbosity to Detailed. It should give you an idea of why it is rebuilding all the projects.
If I understand you right, you might solve this by touching all your project's files. It may be caused by a source-file having a last-modified-time that's in the future.
Edit:
I know that I can solve this specific case, by (e.g.) touching all of the project files, but I'd like to add something to my personal box of tricks that I can use in the future, in the general case.
I'm confused - what's the 'general case' of this problem?
Not that I've found. If you know that a project is not going to change often, you can tell the Configuration Manager not to build it. (Right-click on the Solution, and select Configuration Management)
As far as I know ctrl + shift + b is by default bound to BuildSolution, so that would be why all your projects are being build. i'm not really sure what else you could use except for rightclicking the project and pressing build :)
You might want to check in Tools>Option>Projects and Solutions and check if your option is set to Only Build startup project and dependencies instead of all the solution.
Or instead of using ctrl+shirt+b you should simply press F6 on the project you want to build :)
You can use shift+F6 to build just the current project.
While not directly answering my question: "is there a tool that'll work this out for me?", I found the specific problem by using SysInternals Process Monitor:
The project was configured with /analyze, which requires Visual Studio Team Edition, but the version on this PC is Visual Studio Professional, which doesn't support it. Unfortunately, there appears to be a bug in Visual Studio, where it thinks that the .pchast file should be created, even though it has no way to do so. I've raised this on Connect.
I think I might write a macro for Visual Studio Professional that, if /analyze is turned on, simply creates an empty .pchast file at the end of the build...