I am trying to find some sort of setting in Visual Studio that controls whether it Builds all the report in the solution before letting the user Preview a report.
Currently, I am updating an old report. When I try to preview, the Visual Studio preview goes blank white for about 10 minutes then gives a bunch of errors about issues with different reports.
The report preview failed because the report could not be built.
Unfortunately, Microsoft's MSDN is pretty much useless when searching for something (or anytime you want actual information and not theory). I've looked through every item in the Visual Studio menu but haven't found anything that sounds close to what I want.
It did not build all reports last week when I made changes to another report. I have other solutions which do not currently have the problem (it would make more sense if they did, tho). What setting did I change to make this stupid functionality?
I would recommend opening that report in Report Builder. It's a free download. You can use the 3.0 version or 2016. That way it will not be bogged down by the other reports, it has simpler error handling, and it has pretty much all the same editing capabilities. Once you're done making any changes, you can continue to manage it from within Visual Studio SSDT.
This is not intended as an answer but too long for a comment.
If a report has not been successfully built previously, it will be built when you preview any report. Once the build completes, reports are skipped unless they have been changed since the last succesful build.
Usually when you preview a report, it builds just that report and skips the others.
You can prove this by going to a 'working' solution/project, right-clicking the solution and choosing Clean Solution. This will delete the build info for all the reports, next time you preview any report, every report will be rebuilt, you can see this in the Output window.
Once this is complete, preview any report and in the Output windows you will see Skipping 'report name.rdl'. Item is up to date.
I 'think' the status of each report is held in the project user options file (*.rptpoj.user) but I don't have anything that I can read the file sensibly with so I'm not 100% certain.
You may have to create new project and copy each report in one at a time fixing them as you go, I can't think of anything else, but hopefully somebody know more than me.
Related
How can I make my code build to fail when ReSharper detects an "Error" after code inspection?
I am using C# in Visual Studio 2017 along with ReSharper. I have set the inspection severity of Possible 'System.NullReferenceException' to show as "Error". This setting only shows a red underline for erroneous code, however the VS build still succeeds if I just ignore it. I want to make the build to fail if developer ignores such errors detected by ReSharper inspection.
I'm afraid Resharper seems to not support this option for now.
1.In my opinion, the error level in C#\Potential Code Quality Issues is something like showing a red underline to indicate where there maybe has a risk to help improve your code. And red to indicate this issue deserves attention. Actually,it's something controlled by us, we determine to make them error(red line) or warning(blue line?).
But such a potential code issue can't be recognized by msbuild (build system in vs). So the build will ignore these potential issues and succeeds.
2.For build settings in Resharper, I tried msbuild settings and compiler settings like below:
I set every element in the Potential Code Quality Issues to error. Also, i set null reference related settings like below:
After that I create a simple null reference but the build ignores that and succeeds. Same result when I use Resharper build.(Resharper options=>Tools=>Build=>Build engine) So maybe it's a negative answer :(
This isn't an ideal solution, but JetBrains provide a command line tool called InspectCode which runs their code inspections on your solution and outputs the results in XML or other formats. You could add a custom MSBuild step which runs InspectCode.exe MySolution.sln -o=output.xml, examines output.xml for errors, and fails the build if any are found.
Unfortunately InspectCode is slow and even though the analyses seem to be cached across runs it still takes a significant amount of time. For example, on my solution of 700k lines of code the tool takes 60 seconds on the second run, i.e. with a warm cache. So I don't think this is a viable solution to run on developer machines on every build. It might be acceptable in an automated build system.
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.
We do use TFS to do automatic build and tests with our checkins.
Today we verified old builds we have done last week. We were seeking one specific : 2010/10/27 (5). For some kind of reason it was not showing when we opened TFS/Project/Builds in visual studio (or the build tab in TFS Web).
Here is a screenshot that shows what we saw:
(Bigger screenshot here : http://i55.tinypic.com/35lt1z6.png )
For some reason some builds are jumping, tho I can attest that each builds are iterating and on the 27th there was a 5th build.
Is there something that can prevent TFS from showing complete builds history ?
Did you check the retention policy? It removes builds when there are more then N builds.
Look at the Date Filter drop down at the upper right corner of your screen shot which is currently set for last 7 days.
It may sound obvious, but if you didn't lock the build, then it's also pretty easy to press delete on it (although hopefully the confirmation dialog would save you).
If the build's drop folder is still in your file system, then pretty much all the information on the build is still safe, even if the build has been dropped from your TFS database.
(The only problem I've seen with TFS (2005/2008/2010) is that even if you delete builds, they still show up in the WorkItem user interface so testers have to try to choose the build name from a nearly infinite list - so of course they type something sort-of-like the build number into the field. Sigh)
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.