This has been bothering me for a long time. I am unable to debug SSIS package efficiently because the Variables collection of SSIS package is always empty.
SS of Locals window showing blank value for Variables collection variable
Updated after userfl89 gave an alternative solution
Also, the watch window is showing unable to evaluate the expression error message
I found a similar issue in general VS development environments (C#, VB.NET) and tried suggestions/answers. For example, changing Debug->Options->Debugging-> check Managed c++ compatibility mode (see ss below) but it did not work for me.
SS of debugging setting:
I have also tried to run in both 64bit mode and 32bit mode, but this also did not work. However, I can see variable values inside script task written in C# code. It has become a painful task to debug packages. Please someone help.
Environment:
Windows 7 Enterprise (64bit)
Visual studio 2012 for Data Tools (version 11.0.6xxx)
.Net Framework 4.6
I'm assuming that you already set a breakpoint? When the package hits the breakpoint, on the top menu go to Debug > Windows > Locals and from here expand the top variables node, however it looks like you've already done this. You can also view the variables values in the Watch windows by typing the name of the variable in the Name field when the breakpoint is reached. This will only be the variable name, not the #[User::Variable] syntax.
Related
During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.
A couple days ago I tried to initialize Visual Studio Code to be able to code in C++ using online instructions. They ended up not working at all, but I had edited some settings files (such as a .json file) in Visual Studio Code that I thought were all C++ specific. Afterwards, however, I no longer have the convenient "run | debug" buttons appearing above any "main" functions that I make in java files. In the past I used to be able to just click run and my program would run in the terminal at the bottom of the screen, as opposed to manually compiling and running the program using a terminal. I am running Windows 10. Does anyone know of any way to get these buttons back?
This is an example of what the two buttons look like, appearing above any main functions in a java program.
I also found on the Visual Studio Code website a description of how to begin debugging, attached here, that describes that you need Language Support for Java(TM) by Redhat in order to get these two buttons. I have this extension downloaded, but it is still not working. Please help if you recognize this issue!
What worked for me:
Make sure you have Java extensions, Java Debugger and other basic Java packages installed.
Then making sure the main function is formatted properly like below allowed the Run|Debug buttons to be seen.
public static void main(String[] args) {}
First of all, for troubleshooting, actually we need to have a reproduce steps which can understand what happened in your environment. So can you tell us what you have done to your settings first?
Second, there is a setting under common setting tab, that is Java>Debug>Settings>Enable Run Debug Code Lens. Please check whether this option has been unchecked. Although I think it should not be changed by you.
InstallShield must be the crappiest "industry standard" application in existence, for reasons too numerous to enumerate here. However, one of those deficiencies is something I'd like to be able to fix, and with my first foray into writing an extension for Visual Studio (currently using 2015 version).
InstallShield has created a .isproj type, to allow integration with Visual Studio. This allows a developer to create an installer that references the output of a project as the files to include in the installer (rather than having to manually select individual files to include). This works well enough as long as the .isproj is being built in Visual Studio, and in a solution that references the project for which you need the output.
However, I also have an automated build for my installer projects, that we run on a build server using MSBuild. When attempting to build this way, we were getting completely opaque error messages indicating that the project output references above couldn't be resolved.
As with all InstallShield errors, Googling for answers turned up nothing except for multitudes of other people having the same problem. So I decided to dig into the plain text of the .isproj to see what I could find.
As it turns out, the .isproj type is a just a regular MSBuild script, and it even has lines commented out that explain options that can be added to the project; one of those things that can be added is an ItemGroup containing ProjectReference nodes. Manually adding the nodes helped solve the problem. Command-line build now works.
However, I am dissatisfied with a) having to manually type this stuff in, b) having no visual representation of what projects are being referenced, and c) not finding out about a problem until the build fails. So, I would like to be able to extend Visual Studio to help me with this. Here's what I'd like to do:
1) Add a "References" node to the project in Solution Explorer that acts like the References node for any normal .csproj.
2) Restrict the available References to other projects in the the current solution.
3) Visually represent a project with missing references (e.g. by underlining the project name with a colored squiggly, as with errors/warnings), and potentially failing the build if missing (depending on whether I want to treat it as an error or a warning; TBD).
To these ends, I've downloaded MPF for Projects - Visual Studio 2013, which provides an SDK for creating a new project type.
However, before digging too deeply, I need to know if it's even possible to EXTEND an existing project type, as described above, as I obviously don't have InstallShield source code. Also, any links or guidance as to a starting point for doing so would be greatly appreciated.
I am using Visual Studio 2012 with the Intel Fortran Compiler XE 13.0 (from Parallel Studio 2013) to code in Fortran.
When debugging a project, the "Locals" and "Auto" windows don't show any variable. Similarly, when hovering over a variable name in the code, I don't get any datatip showing its value. Lastly, when trying to evaluate a variable or expression in the Watches I always get an "Unable to evaluate expression". So, as far as I understand, there's some problem involving debugger symbols or something like this.
Here's what I tried:
restarting VS and Windows
creating a new solution with default configuration
checking the Debugging options for any obvious setting which could case this
followed this answer, even if it looks like it's for a slightly different problem (VS recognizes a local variable, but saying it's out of scope)
repairing my Intel Parallel Studio XE 2013 installation
I never enabled optimization. Here's a screenshot so that you can clearly see what it's going on here.
P.S: as a last hint, I found a similar bug affecting VS2010, but 1) yeah, I've got VS2012 and I suppose it should have been fixed 2) it affects C++ (don't know if this matters though) 3) the patch is not directly available online.
Possible duplicate of this question.
I have a MFC project that uses /clr switch and some C++/CLI code to use a .Net component. Originally this was on VS2005.
On upgrading to VS2012 Update 2, during debugging, no values or types were shown for native data types. I learned that a new mechanism for native data type visualization (natvis) was introduced in VS2010 and extended / enhanced in VS2012. Following the information on that page, I unchecked Managed C++ Compatibility Mode and C/C++ edit and continue. After this, breakpoints became disabled and stopped being hit. Using "Only Managed" debugger, the breakpoints were hit but no values were shown.
Finally, I used "mixed" debugger and used __debugbreak() to force a break. This resulted in only integer values being shown ONLY if they are local autos; and data types were picked up correctly. However, std::string or CString values are not shown and instead their type is shown in value column. Similarly, pointers, class members, or functions argument values are not shown and type information, Undefined value, or out of scope is shown in the value column.
The behavior is consistent across autos, locals and watch windows as well as mouse hover on symbols.
How do I get the native data types to display their values during debugging in VS2012 mixed mode C++/CLI MFC application.
I have read this question and verified that all symbols have been loaded in modules window.
Apparently, Microsoft is aware of the issue and the upcoming CTP of Update 3 should fix it.
Additionally, why do I need to use __debugbreak()?
A couple of days ago, Microsoft released a Visual Studio Service Pack 3 RC which may help (installing it myself right now). Here is the link: http://www.microsoft.com/en-us/download/details.aspx?id=38832
Re-install Visual Studio 2012 and do not apply Service Pack 2.