I am new to using Microsoft development tools but have been using Visual Studio 2010, .NET 4 and C# for the past few weeks. I ran into a problem yesterday creating a new project the same way I have been doing it successfully from the start: right-click on the project in the Solution Explorer → Add Reference, which used to bring up this dialog:
Old Dialog Box http://img514.imageshack.us/img514/8978/oldaddreferencedialogue.jpg
After a couple of weeks of no new projects I went to create one yesterday and got a new Add Reference dialog. And trying to add the same dll I have been adding for weeks now resulted in the error seen here:
New Dialog http://img692.imageshack.us/img692/2074/newaddreferencedialogue.png
So, after a painful day trying to determine the cause, it looks to me like it has something to do with the new dialog choking on the # I had in my reference path. When I removed the # everything works as expected. Considering Microsoft has two .NET languages with # in the name, I am surprised that this issue keeps biting people (I have heard of this problem over the years, but I have never done much with Microsoft tools until recently, so of course I did not recall it.)
Questions from a Visual Studio newbie:
Is it common knowledge to not use # in paths?
How/why did I get this new Add Reference dialog when my colleagues, using the same VS version, still have the old dialog that handles # in paths just fine?
My opinion is that if you use weird characters in paths, you get what you deserve. :)
I know there are bugs about '#' character in paths in the core VS product, in addition to whatever may be in the Pro Power Tools extension. There is a surprising amount of code that goes to/from URIs and filenames, and '#' characters (and everything thereafter) get dropped when roundtripping via a System.Uri.
In general, I think it's safe to assume that when creating filenames/paths, there will be 10,000 tools of various quality trying to parse the filenames, and a (large) subset of those tools will fail on 'weird' characters. Just avoid weird characters whenever possible. You gotta choose your battles. In an ideal world, tools would be robust to these kinds of issues. In the real world, it's better to name a path "CSharp" rather than "C#" and move on with more important things in life.
The second dialog is the one from the VS2010 productivity power tools pack - I havent used it myself so dont know of any problems with it. Have you recently installed this?
Related
I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
I have been tasked with reviewing "SAP Crystal Reports for Visual Studio 2010" and the "SAP Crystal Reports 2011" standalone as potential upgrade paths from Crystal Reports v10.
I've installed the extension to Visual Studio 2010 (and went through the common troubles of updating the runtime to get the viewer working) and can open report files and save them. Consequently, I get the "this report was saved in a previous version of CR, saving will upgrade the report file format" dialog. I've tested on a couple of reports and the conversion goes ahead smoothly and the resultant file remains compatible with our server software.
My problem is I have over 1,500 reports. I'd like to avoid opening each one in turn and saving/converting individually. Is there a way to convert all the report files in one fell swoop? Some means of scripting Visual Studio to do it, maybe?
Notes:
I've added every report file to a project and attempted to Save All... no dice.
I must convert every single report now. It's not an option to just convert those that need changes when they need changes.
My work network access is locked down pretty tight. The bureaucratic process to get any utilities or tools installed on my machine is INTENSE and must be justified.
We don't use any features of CR standalone that aren't shipped with VS.
P.S. It's worth re-iterating that I'm also reviewing CR2011. I'll need to do the same thing with the standalone designer too.
Why not use Windows PowerShell? I've written a PowerShell wrapper around the Crystal Reports SDK named PsCrystal. My goal is to make it easier to script the mundane tasks that I encounter each day.
You should be able to adapt the (sole) example to suit your needs. I will add more examples in the near future. Feel free to help the project, if you want.
Check if this tool will work for you:
http://www.r-tag.com/Pages/CRDataSource.aspx
It is actually replacing the connection, but will upgrade the reports too.
Thanks to Craig and Lan for their input (you get an upvote), but Ryan addressed my problem within the comments of my question (and even did so after I gave him sass!).
For those with broken scroll-wheels and/or extraordinarily short screens:
For VS2010, you could easily create a simple program to open each .rpt
file in a directory and then re-save it (The web is full of examples
in the language of your choice). Doing this in CR2011 is a little
trickier... I'd try a script in something like AutoIT.
Thanks, Ryan, for reminding me that I'm working with an API. Not just a dev environment.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
To preface this I am an Emacs refugee on Visual Studio 2010's shores and am certain that I am working against the tool. Please could someone point me in the right direction. My problem is the MyProject.csproj file is kept under version control using TFS and my coworkers have made a number of changes that no longer get along with my version. Not a problem, I can just merge the changes and make things right. But I can't, or rather I don't know how to. The compare tool in VS only taunts me, it won't let me pick and choose differences like I need to.
What I would love to do is just use Merge in Emacs, run through the file hitting L(eft), R(ight), B(oth) and be done with it in no time. What I don't understand is why there are certain changes that are accepted by default, that I cannot alter. I think that what it is doing is identifying changes that I made to the ancestor document and forcing those to be made while providing me the option of merging the changes from my coworkers. My issue is that these things are contradictory and I would like to ignore my change to Line 12 while accepting the Repository's Line 42 but applying my Line 106.
But I cannot figure out how to tell it "no" to Line 12.
This has to be common, what does one do in VS to get this to work?
Thanks!
The standard diff tool that comes with Visual Studio ... blows. Its not intuitive and doesn't work all that well.
But its very easy to integrate different diff tools. I'm using this one:
http://visualstudiogallery.msdn.microsoft.com/en-us/dace3633-0b51-4629-85d4-c59cdce5bb3b?SRC=VSIDE
(no affiliation; its free so don't ding me for spam kthx). Works pretty damn good. You might find one out there better suited for your tastes, in which case you can integrate it into visual studio. (again, not associated with me!)
I advise you to use WinMerge to compare or merge files with VS
You can define as Will said.
Bookmarks: In VS 5 they seemed like a great idea but I ended up not using them mainly because they didn't persist between sessions. E.g. If you closed a file that contained bookmarks they would not be there the next time you opened the file. You also could not move between bookmarks in different files etc. and I stopped using the feature.
For years I would kill the bookmarks toolbar whenever I installed VS. It took me years of using VS 2005 until I noticed that the bookmarks feature had actually been greatly enhanced and I use them on a daily basis.
Have you ignored Visual Studio features and later discovered their value?
It wasn't so much ignoring VS features as it was being ignorant of them, but for a while I didn't use custom project/item templates and code snippets, even though there was significant boiler plate code at my last job that was easily fixed by using these. I used the default templates for a while until I realized I could customize them for our application, and it's saved me loads of time since then. Code snippets I used to a lesser extent, but I do find them useful for smaller bits of code.
The other "feature" I find infinitely useful these days is "Delete all breakpoints" (CTRL-Shift-F9). I used to keep all of my breakpoints around, and they would persist in each solution...but it would 1) slow down VS load times, and 2) disrupt my debugging behavior by breakpointing in sections of code that I didn't need to breakpoint in anymore. Instead of manually removing them, I got into the habit of removing all of them, and then placing a few key ones around code I really needed to test. This was more contextual though - initially having a ton of breakpoints was useful to learn the codebase, but once I was familiar with it, isolating bugs was a lot easier without all of the breakpoints hanging around.
Macros for repetive keystrokes
The code palate (part of the toolbox) for storing my fave code clips
T4 toolkit for generating code
Customize the top toolbars to remove stupid shortcuts (like copy/cut/paste, undo/redo) and add ones I ALWAYS use (comment/uncomment block, step into/over/out)