I applied the SQL Server Data Tools patch to Visual Studio 2012 (Premium) and created a SQL Server CLR user-defined function project in C#:
public partial class UserDefinedFunctions
{
[Microsoft.SqlServer.Server.SqlFunction]
public static SqlInt32 Add42(SqlInt32 in_param)
{
SqlInt32 retval = in_param + 42; // Set break point here.
return retval;
}
}
In the SQL Server Object Explorer pane, I right-click on the newly published UDF and select "Execute Function..." I am prompted to supply a sample input value, and Visual Studio then publishes the function (again) to my local 2012 SQL Server and generates a script that looks like this:
DECLARE #return_value Int
EXEC #return_value = [dbo].[Add42] #in_param = 5
SELECT #return_value as 'Return Value'
GO
... and executes it, returning the expected result of 47.
If I now put a break point on an executable line in my CLR UDF C# code, right-click the UDF function in SQL Server Object Explorer, and this time select "Debug Function...", I land in a debugger for the generated SQL test script. I can step through the SQL statements to the end of the script, which returns the correct result, but the breakpoint in my C# code is never reached in the C# debugger.
The terminology for this feature seems misleading. To any programmer, "debugging" a function means stepping through the executable lines in the code of the function itself. Simply generating a SQL test harness that calls my compiled function and gets back the result is just "testing" the function. At most, the only thing being "debugged" is the tool-generated test itself, because you can't "Step Into" the CLR code. The only option is to "Step Over" it.
So how do I get Visual Studio to actually debug, and hit the breakpoint in my UDF C# code?
Okay, I finally figured this out. To debug SQL CLR code in VS 2012:
Create a SQL test script that calls the UDF, sproc, or other CLR object.
(You can do this by using the "Execute Function" or "Debug Function" options in the
Server Object Explorer, as described in the question.)
Save the generated script. (It will be called something like
"SQLQuery1.sql" by default. You may wish to give it a more
meaningful name.)
In Solution Explorer, right-click the UDF (or other CLR type)
project, and select "Properties".
The project's properties tab will open. On the left, select the
"Debug" category.
In the "Start Action" subcategory of the Debug panel, select the "Startup script:"
radio button. This will enable the associated dropdown so that
you can specify the .sql script created in Step 1.
Save all, toggle a breakpoint on an executable line of your C# or other .NET language
code, and press the debug button.
NOTE: You may now get a dialog telling you that "Windows Firewall has blocked some features of this program." I checked the boxes to allow access to domain and private networks.
Proceeding now should cause your breakpoint to be reached.
For Visual Studio 2015 + Update 2:
In SQL Server Object Explorer pane, right-click on the server and select "Allow SQL/CLR Debugging":
In Server Explorer, right click on the function you want to debug, and select Execute:
It will generate the code for you. Select Execute with Debugger:
You can then place a breakpoint in your C# code, and it will hit it.
It will ask to open a port in your firewall, and it will ask to attach to SQL Server.
I do not know if SSDT changes this, but in VS2008 I debug a .net UDF as follows:
I deploy it to my local SQL server,
then I attach VS to the SQL Server process (Menu Debug/Attach to process/sqlserver.exe, if SQL Server is running as a service it requires that VS was started as administrator).
Then execute some SQL code calling the UDF, e. g. in Management Studio. Maybe this will work from SSDT in VS 2012.
The patch you applied may install VS items which are not current with the Visual Studio Quarterly update. I recommend that you now apply the latest Visual Studio Quarterly Update for VS 2012.
Related
I'm developing SSIS packages on Visual Studio Community 2015 (version 14.0.25431.01 Update 3) with SSDT (version 14.0.61707.300) where I often use SSIS Script Tasks in C#.
My Packages are developed locally and then tested on various servers.
The problem I face is the following: sometimes, when moving the Package/Solution to another computer or simply when restarting my local VS, I launch the Package and it fails at the Script task step, with the commonly known "unreadable" error message.
Strange thing here is:
My script worked the day before, without any problem
My script is embedded in a try {} catch { MessageBox.Show()} which should pick up the more precise error message and display it in a MessageBox but somehow doesn't.
The weirdest thing is:
If I open the Script Task (dble click on it)
Then "Edit Script"
Change nothing to the script
Close it and click on "OK", so that somehow the non-modification is saved
Then save and launch the package
IT WORKS!!!
This wouldn't be too much of a problem if that random incident didn't happen every once in a while, even while in PROD...
Have you ever had this problem? Have you found a solution?
Note: this incident already happened on previous versions of SSDT, so don't look into that too much...
I can't even find similar problems in Google...
A few things here
When a script task/component doesn't work but opening it and resaving it fixes it, then something happened to SSIS package to wipe out the compiled bits in the package. When you have the Script's instance of Visual Studio open, when you compile/save/exit the script, behind the scenes what happens is the resulting assembly is serialized and stored into the SSIS package's XML.
Back in the 2005 era, the default behaviour was the Script itself was saved and then compiled and executed when needed but that introduced a host of other issues so now the script's bytes are saved into the package instead. Larger package now due the bits versus text but who cares about package size on disk at this point?
So, your task when this random incident occurs is to play Monsieur Lecoq and find out what happened to make the package change. Usual culprit is someone has deployed a newer version and broken yours but there a host of options here that made it go bad. Besides checking logs, etc, I would download/save the package to my local machine as Package.v1.dtsx. Copy paste that so I have Pacakge.v2.dtsx and open v2 in Visual Studio. Open the Script, Build, Save and then Save the package and look at the resulting .dtsx files in a text editor with a compare feature. Essentially what you're looking for is the Script Task's beginning tag and see what's in V1 which might be empty or mangled and compare that to what's in V2. It's all gonna be encoded binary but I'd at least confirm there is content in V1.
Another option is that there's a Version difference somewhere in the mix. The act of touching a package with a higher level of SSIS tooling can result in the binary getting updated to match the newer which presents a problem when it's deployed down a level. You build packages for SQL Server 2016. I deploy the packages using SSDT tooling for SQL Server 2017 to our shared SQL Server 2016 server. That deploy upgrades your packages in memory to 2017 which is then written to a 2016 instance and then bad things happen. But that's usually a different error. Versions can also be an issue when compatible updates happen. You target SQL 2014, I use SQL server 2016 Tooling to deploy to our 2016 and some times, deploy goes great but other times, especially if it's a Script Component that acts as a Source, the difference in version signature for the data flow can make things "weird."
Finally a good practice is to not have a MessageBox in your code. The reason for this, is that if the MessageBox attempts to fire when the package is running in an unattended state, no one can click the box to dismiss it so it will instead throw an exception. If you insist, then pass the System scoped variable InteractiveMode to your scripts. That Variable indicates whether SSIS can interact with the desktop aka show a message box.
if ((bool)this.Dts.Variables["System::InteractiveMode"].Value)
{
MessageBox.Show("My Message here");
}
I strongly prefer to raise Information events and use the following pattern. Add all the variables I care about as ReadOnly variables to my Script and then my Main looks like
public void Main()
{
bool fireAgain = false;
string message = "{0}::{1} : {2}";
foreach (var item in Dts.Variables)
{
Dts.Events.FireInformation(0, "SCR Echo Back", string.Format(message, item.Namespace, item.Name, item.Value), string.Empty, 0, ref fireAgain);
}
Dts.TaskResult = (int)ScriptResults.Success;
}
Now your data shows up in the Results tab and the Output window (where you can copy it) in Visual Studio execution and when you run it on the server, it will be in the SSISDB.catalog.operation_messages
I'm using visual studio 2013 and I'm trying to open an SQL data table from the server explorer but it gives me an error which says
the designer encountered an error while loading the table definition
I also tried opening it from the SQL Server object explorer but it still gives me the same error, how can I solve that?
You can try one of the following:
simply disconnecting from the server and reconnecting
Verify that the database in VS has the necessary permissions to create tables
verify database name: Go to Server explorer -> right click on your database -> Modify connection.. -> under "Connect to a database name:" select your correct database name.
alternatively you can use SSMS for to get to the same result: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
It may occur due to insufficient memory.You can check following link for reference.
https://farcajr.wordpress.com/2017/03/21/the-designer-encountered-an-error-while-loading-the-table-definition-solution-in-visual-studio/
I have Microsoft Visual Studio Professional 2012 installed, version 11.0.60610.01 Update 3.
When debugging a c# (.cs) file Visual Studio gives me the following message when I try to set a breakpoint:
"A breakpoint could not be inserted at this location".
I get this message even when trying to set it on a line within a method. But in a .vb file for a Visual Basic app, I can set a breakpoint.
I am wondering if anyone has any suggestions to resolve this or if I need to reinstall visual studio.
Thanks
Maybe I'm too late for this question but here it goes anyway,
BUILD > Clean Solution
BUILD > Build Solution
I have encountered a similar issue and I resolved it by exiting Visual Studio and deleting the .suo file from my solution folder.
This file is recreated when you open the project again and it is not harmful to delete it.
The .suo is used for storing the layout of your solutions, the breakpoints you've set, the tabs you had open, etcetera.
I am not sure why this worked but my logic was that Visual Studio thought I was trying to place a breakpoint in a location different to where I was actually placing it.
I was finally able to find a solution for this. I had to do a repair on my Visual Studio 2012 instance through the control panel -> Programs and Features, right clicking on Microsoft Visual Studio Professional 2012, and selecting change. In the Visual Studio window I then selected repair.
As part of the repair process, I also had to download web deploy located here: http://www.microsoft.com/en-us/download/details.aspx?id=4148 and point the visual studio repair process to the .msi file when it said it couldn't find the web deploy package and could not download it from the internet.
I also had to implement the fix indicated in the following stackoverflow question: Plain C# Editor in Visual Studio 2012 (No intellisense, no indentation, no code highlighting)
Now I am able to debug applications as expected.
Well, sheesh...for people as dumb as me, here's one more thing to consider:
You can put breakpoints on the curly braces at the start or close of a method, and you can put breakpoints on any line that is doing something (e.g. assigning a value or calling a method). However, you can't put a breakpoint on a line that is only declaring a variable or otherwise "doing nothing."
E.g. I had a method:
public IEnumerable<SomeObject> GetList()
{
int distance;
var otherVar = SomeValue;
}
I was trying to put the breakpoint on the first line with int distance;, which is something that works fine in other IDEs, but that doesn't work in VS. I had to go up to the brace or down to the next line with the assignment in order to get the breakpoint to set.
5 minutes of my life wasted, that I'll never get back, trying to debug a non-issue ;-p
VS 2017
I had this, I was missing an ; inside a for loop
If there is no instructions to execute on a line, VS refuses to set a breakpoint an offers no reason. EG
string str; //Cannot set breakpoint
string str = ""; //Can set breakpoint
I need to embed HTML in a Winforms project and call Javascript functions from it. I'm using a webBrowser control in a c# project and calling:
webBrowser.Navigate("website");
return webBrowser.Document.InvokeScript("myMethod", new object[]{"test"});
How can I debug execution of code when the debugger is in "myMethod"?
There's this article on how to debug HTML from IE:
http://www.codeproject.com/Articles/18921/Using-Visual-Studio-to-Debug-JavaScript-in-IE
I don't know how relevant it is though.
Add following "debugger" line in your website's "myMethod" function -\
function myMethod(arg1, arg2)
{
// when myMethod executes you will get prompt that with which
// debugger you want to execute
// then from prompt select "New Instance of Visual Studio 2xxx"
debugger;
//
...
...
}
"debugger" statement will prompt for debugging the JavaScript.
When myMethod executes you will get prompt that with which
debugger you want to execute then from prompt select "New Instance of Visual Studio 2xxx"
Hope this will help.
In addition to the approach mentioned by Parag, you can also explicitly attach a debugger in Visual Studio and select Attach to: Script code.
Once that's done you get all open scripts to show up in Visual Studio as Script Documents and you can set breakpoints in any of those scripts. You can reuse the same instance for multiple debugging sessions. You also can open a JavaScript Console and DOM Explorer which gives you access to the same tools you'd get in full Internet Explorer.
More detail in a blog post here: https://weblog.west-wind.com/posts/2017/Jul/06/JavaScript-Debugging-in-a-Web-Browser-Control-with-Visual-Studio
Note: Visual Studio 2019 makes script debugging a little harder to set up and unfortunately no longer supports the Console View/Evaluation window. You can still step and debug value, but no real time evaluation or seeing console.log output.
I'm doing some visual studio extension development in Visual Studio 2010.
It would be useful to debug while developing so I have it configured to open another instance of VS when debugger for F5 ( http://donovanbrown.com/post/How-to-debug-a-Visual-Studio-Extension.aspx). This all works fine but is there a way to attach a debugger to an existing instance of VS2010, I have tried and the breakpoints aren't being hit. There are no errors but wondering if there is a way?
I should add I do know how to attach to a debugger and I have used it before to attach to ASP.net code.
Under Debug there is a item called Attach to Process. This will do exactly what you want it to do.
Use the Title column to tell which instance of devenv.exe you want to connect to (notice that I started the attach on BinaryFileSearch, but I am attaching to FixClientNoteRTF).
It does not let you attach to yourself because if you hit a breakepoint the UI would stop responding and how would you tell it to step or continue?
OK managed to solve it.
What I was doing was when opening an instance of Visual studio, following the usual method, i.e. open a normal instance ( devenv.exe).
What you have to is open a experiemental instance, using the parameters ( cmd line mode):
/rootsuffix Exp
Then use the attach to debugger mode to attach to this instance.