visual studio (SSDT) 2017 unable to start debuggin

问题:

I recently installed a Visual Studio 2017 from SSDT package. I am testing a simple scenario a flat file source and an OLEDB destination with no C# or VB scripts involved, as well there are no debugging breakpoints in the code. When I try to execute package for SSIS project I get the error:

Microsoft Visual Studio Unable to start debugging. The debugger is not properly installed. Run setup to install or repair the debugger.

------------------------------ ADDITIONAL INFORMATION:

Unable to run program „DTS”.

DLL library of Visual Studio program named coloader80.dll is not properly installed. Repair the Visual Studio installation by using applet Add or Remove programs in Control panel.

If the problem persists you can manually register the coloader80.dll library >from command line, using instruction „regsvr32 "%CommonProgramFiles%\Microsoft Shared\VS7Debug\coloader80.dll"”. (Microsoft Visual Studio Debugger)

I tried to use the solution for a similar problem: https://developercommunity.visualstudio.com/content/problem/26630/the-debugger-is-not-properly-installed-cannot-debu.html

I removed the content of C:/Program files/Common Files/Microsoft shared/VS7Debug folder and reinstalled the VS, but it doesn't seem to work in my case.

Any other ideas would be appreciated.

回答1:

I tried the sames solutions with no result.

Today I solved with this solution:

https://stackoverflow.com/questions/37299032/visual-studio-2015-the-hash-value-is-not-correct​

> 1. Download: https://go.microsoft.com/fwlink/?LinkId=866452
> 2. SSDT-Setup-ENU.exe /layout <folder name>
> 3. Download: https://aka.ms/vs/15/release/vs_sql.exe
> 4. vs_SQL.exe --layout <different folder name> (this takes a while, it's laying out ~4 GB)
> 5. <different folder name>\vs_setup.exe --wait --nickname "SSDT" --passive
> 6. <folder name>\SSDT-Setup-ENU.exe

回答2:

I am taking a stab in the dark here because you question is lacking in detail. But, my best guess at the steps taken to produce the error are as follows:

1. You are using either a C# Script Task (Control Flow) or C# Script Component (Data Flow, which has a break-point in it
2. You are able to successfully compile and execute the package
3. The job runs until it reaches the C# component that has a break-point in it and then sits there running continuously without any progress or failure
4. The VSTA debugger is not launching
5. The error message that you have provided is showing up in the Execution Results tab (i.e., the log)

If this is the case, then I believe you have ran into a bug within the VSTA debugger where it cannot launch because you are doing something in the code that it does not like - this is unhelpful by Microsoft of course. Additionally, what this means is that it is unlikely that there is anything wrong with your installation of Visual Studio, SSDT, or VSTA. It is more likely that there is something in your code that the VSTA debugger does not like, which is causing it not to launch while also throwing a misleading error message.

To confirm this, you will need to comment out sections of your code and run the package in order to find what code is preventing the debugger from launching. Once the debugger launches, you have isolated the section of code that the debugger cannot run for.

If the un-commented section of code is where the problem is (i.e., creating the incorrect result that cannot be debugged), try finding a workaround. Otherwise, if you know that the un-commented section of code works just fine, then leave it commented out (or plug the value for whatever it is doing if other parts of error code are dependent on it) and continue debugging other parts of your code.

Known debugger issues that prevent the debugger from launching:

1. String interpolation is being used.

Workaround: Use string.format("String text here with variable param here {0} and here {1}", param1, param2);

2. TryGetValue is being used on a dictionary to see if a value exists before retrieving it.

Workaround: None that I am aware of. See my question on the issue at:

SSIS VSTA: Why does Script Component debugger not work when using TryGetValue on a dictionary?

If your issue does not fall into either of the above, then I would like to know what new issue you have found, and what workaround you created, as that would be beneficial for me to know (I dev. a lot in SSIS/C#). I can assist with developing a workaround if you are having any troubles with it.

Note: If commenting out all of your code still prevents the debugger from working, then try adding a new C# component that does something simple, like display a message box or set a variable value (i.e., int intValue = 1;). If that still doesn't work, then you might want to consider re-installing VSTA and SSDT. Hopefully you do not have to take this step.

回答3:

I recommend trying to re-install. Note: using the installers to uninstall and re-install does not remove everything, which can cause problems to persist. See the below for how to remove everything, which includes manual steps you must take.

Upgrading SSDT was a challenge in its own right because Microsoft notes on the SSDT download page that it is IMPORTANT to first uninstall SSDT and then reinstall SSDT. However, when running the uninstaller for SSDT it warns the user that not all components will be uninstalled because it will leave the computer in an unsupported state and that these components will need to be removed manually in the Control Panel (i.e., under Programs and Features). The problem here is that Microsoft does not specify which components need to be uninstalled. I had to reach out to our Microsoft Premier Support technician and they were able to provide the list of components to uninstall (see weblink image below).

Note: In some cases this list is sufficient. However, if you have additional Microsoft Visual C++ 20nn Redistributable (x86/x64) components, then those may need to be uninstalled as well. Otherwise, the SSDT installer may crash. Digging through the installers error log will point this out.

https://1drv.ms/i/s!ArgNRGQ-3kB-dg3-igZcamMEpAk