I am working on a SSIS package that has some script components (in C#) inside data flow.
I used break points all the time with it and worked fine without any issue.
But yesterday suddenly it stopped working without throwing any errors or any.
The script works fine without breaking or any error, giving me the expected results as well but does not stop on break points.
I didn't change any visual studio configurations or project configuration.
Google and tried all the solutions others provided.
Clear all cache and all debug objects, rebuild the solution again, restart the machine as well but none of those worked.
Does anyone have this kind of experience?
Environment: Windows 10 Pro, VS 2017
Beware that if you're using a newer version of Visual Studio than what the SSIS package was created with, you need to avoid C# syntax that the compiler won't understand. If you don't, your breakpoints won't be hit.
For example, I opened a package created in Visual Studio 2015 with Visual Studio 2017. I used the newer "$" string interpolation instead of string.Format() and that caused the debugger to not hit any break points. Reverting the string interpolation back to string.Format() got the debugger working again.
Had the same issue.
Spent half a day on this, should have checked my notes, because I found this and solved it before, at least for me.
Upgraded to the latest VS2017 and SSDT as of today, no help. Finally created a simple package with just a dataflow that had a csv source, and script transformation component, and a recordset destination. Set a breakpoint in the script component, and it worked.
Compared project properties with my "real" project and found that Configuration Properties | Debugging | InteractiveMode was False; it was True in the test project. Set it to True in the real project, and the breakpoint worked.
I had forgotten that I set it False to test package error handling.
At last found the reason for the issue, the reason is that I used a conditional access operator inside the script.
The compiler compiles the code properly and works fine but the debugger somehow doesn't understand that operator and crashes.
Seems like SSDT use old C# version on debugging..
Related
I am getting this incredibly annoying warning for every C# file in my ASP.NET Core project when I debug it after hitting F5:
Because this error appears only during runtime (not during build), I can't even suppress it using the "Suppress warnings" box in the project properties. I've tried putting 1003 and ENC1003 in there and it still appears, cluttering up my warnings window. Does anyone know why this thing is appearing and how I can get rid of it?
UPDATE: It doesn't fix the fundamental problem which is that the warning is generated in the first place, but I've found a way to suppress it. Create a GlobalSuppressions.cs file at the project root, and add the line:
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(null, "ENC1003")]
Related Github issue: https://github.com/aspnet/AspNetCore/issues/13284
Try to get the Lastest Version of your Visual Studio and try again, If Persist, Install Visual Studio 2019 v16.4 Preview 2.
Also Check out the following content>> https://developercommunity.visualstudio.com/content/problem/601258/edits-were-made-to-the-code-which-cannot-be-applie.html. You can also track this same issue on ASP.NET Github: https://github.com/aspnet/AspNetCore/issues/13284. We already have a fix for it, which will be available on Visual Studio 16.4 Preview 2
I was facing the same problem in my Visual Studio 2019, and therefore I had to update VS to the latest version and I was good to go.
Hope helps someone :) :)
You can go to build options and select the option to build solution (build->build solution), this should solve the problem and you will able to continue your project in solution mode.
I had this problem also in Visual Studio 2022 (17.0.5) running API projects. Restarting Visual Studio helps.
In the past, while debugging UAP apps, if I edit the code while the app is running it will let me know that it needs to recompile the whole application. (Usually when adding some sort of static variable or removing a function etc... Tht in and of itself is not a bug.
The bug is that when I STOP debugging, the error remains until I restart the IDE.
I would argue that suppressing the warning is a horrible idea - It means that you have no way of knowing if the code changes you made during debug were implemented.
Instead, try restarting the IDE and doing a clean and build. I don't remember what I do to make the error go away anymore, as I have not experiences this bug in at least 8 months.
I have one solution in VS 2017 pro, where i am unable to attach process and debug properly.
For start, even though my application is loading/running properly, visual studio attach to process screen always shows 0 Sessions against that app-pool/application.
If i then select it, it never hits any of the C# code (weird).
I manage to hit some razor view cshtml files to be debugged, but never the c# code
any ideas?
My first question if you have started process/service. Then build code do you get error message that exe is already in use?
If not then you are not sure about the correct code.
If then aleast run against your code alomst for sure.
If that not solve your problem. We need to see where you have installed and how to service. Also what the code for the service looks like. It help see where you have your first breakpoint in the code.
Usually if it not reaching the breakpoint or the code is grayed out. It is because the binary is not found or it does not match the code. T
The service you are trying to debug are it installed in your building directory so you are sure is lastes version?
I have been used to use visual studio to create web apps and other application. Visual studio makes it possible to place a breake point on a method, and activate that breakpoint from the client side. And as soon as that method gets called, the debugging will begin, and you can press next etc to see the different values of the variables.
Circumstances for the past 6 months, have required me to use monodevelop, since I am working on ubuntu. I am using nginx as webserver. Many times I have searced for documentation on how to debug from monodevelop. I have not been able to find any solution, and mono's documentation hasn't helped me so far, unfortunately. So to debug my code, I write to a log, which is killing me.
Has anyone successfully found a way to debug code using monodevelop, and activate that breakpoint from the client? Similar to the way in visual studio, that I just described?
Yes, you can set breakpoints in Mono the same way you do in VS. Verify you have installed all the relevant packages before.
http://www.mono-project.com/archived/guidedebugger/
My breakpoints aren't getting hit in Xamarin Studio. I'm not sure if this has to do with my code, or not, but I feel as though it doesn't because I've tried over and over putting breakpoints all over my project (in places where I know they should definitely be hit, and in places that the code works perfectly and is completely unrelated to the feature I'm currently testing) and none of them are getting acknowledged when I debug. I don't have the breakpoints disabled, and I don't have them added in the wrong place. The breakpoints should work normally, and they're not. I'll also add that I'm not allowed to pause my application during the debugging process. I suppose you could say the debugger in my Xamarin Studio isn't working and I have no idea why. I believe I've determined it's unrelated to the code, but I can't be sure about that still. Please help. Thank you.
It is the most popular question about: "breakpoints are not being hit in xamarin" in google, so after whole day of trial and error I am gonna post here a solution for this problem for xamarin versions > 4.0.0.xxx. Yes, sadly this is simple.
SOLUTION
(This solution is for android app in visual studio, but should work in xamarin studio as well)
Remove all symbols from the path to your "Debug" Folder (usually: [path to your .sln file] \ [your solution name] \bin\Debug):
So if you got for example:
G:\My Files\Programming\C# (+ JS)\Test1\Examples\LINQ to Objects\AndroidDemo\AndroidDemo\bin\Debug
Change it to:
G:\My Files\Programming\CSharp\Test1\Examples\LINQ to Objects\AndroidDemo\AndroidDemo\bin\Debug
For me "(" and ")" symbols were causing the trouble (Who is using such symbols in the path anyway right?)
To verify that this is working, open your debug folder, in VIsual Studio Select "Clean Solution", "Recompile Solution", "Deploy".
"Deploy" action should generate *.mdb files which include your debugging data. If they are present, you should now be able to stop at breakpoints.
Now you can simply hit F5 like usual whenever you need to debug something.
I'm not sure if someone is still following this thread, but this workaround worked for me.
The problem sometimes has to do with the mono 5.
So the resolution is to use older version of mono:
Set "Project > Active Runtime" to "Mono 4.8.0 (8f6d0f6) (/Library/Frameworks/Mono.framework/Versions/4.8.0)".
for Mac users, change it in "Preferences" -> ".NET Runtimes"
Then Rebuild the Android app project.
Deleting the BIN folders and any *.SUO file is a favorite fix for this issue.
Can also try deleting any *.csproj.user
In worst case, reset VS Settings by launching (Run) with "Devenv.exe /ResetSettings"
Make sure you have your build configuration set to Debug.
Make sure your project's build settings are set to allow emitting DEBUG symbols for your Debug configuration.
Clean and Rebuild your solution/project.
Close and restart Xamarin Studio.
Reboot your computer.
Sometimes the build configurations for your solution can get complicated, and it's easy to miss something when building a complex build configuration. Make sure everything is setup properly in there.
I encountered this yesterday, using VS 2013 and Xamarin plugin. "All of a sudden" breakpoints in a PCL project were not active, even though breakpoints in an Android project still were. Everything had been working perfectly for weeks, and I had applied no updates. Looking at the VS Debug | Windows | Modules view, I could see that symbols were not loaded for the PCL assembly, and nothing I tried would force them to load, even though they were present in the folder with the running assemblies.
Then I remembered that the last thing I had done the prior day was not related to code, but was a bit of refactoring of csproj files to support a parameterized Jenkins build. I had placed an OutputPath definition in the first "shared" PropertyGroup, and removed it from all of the Configuration/Platform-specific PropertyGroups, e.g.:
<OutputPath>bin\$(Configuration)\</OutputPath>
I deleted this "common" OutputPath and put it back into each specific PropertyGroup (offending my DRY sensibilities, mind you), and things started working again.
This is probably not going to bite very many people, but it wasted a couple of my hours, so hopefully it spares someone else. The Xamarin build probably does some of its MSBuild/xbuild spelunking with strong expectations, so if you've modified your csproj files for a build process, this might be a possible culprit.
I add this answer because this is the only one that worked for me, in Project Properties > Build I wrongly checked Optimize Code.
Unchecking this box solved the issue.
I switched from stable to alpha Channel v.3.11.785 (Alpha). all breakpoints are now hit.
I faced this problem in Xamarin Forms app using Visual Studio for Mac. In my case, it was happened because of debugger. Visual studio was continuously showing "Waiting for the debugger to connect to the iOS simulator..." while running in an iOS simulator. I did reset the simulator (Hardware => Erase All Content and Settings) and cleaned up the solution. Then I could do the debugging with breakpoints. Hope this helps someone.
I had the same problem.
THE CAUSE (IMO):
In my case the problem is caused by Xamarin Studio (but with VS2013 is the same) build/rebuild process.
More in details, the *.mdb files are not correctly regenerated and therefore the debugger does not work properly.
You can check by doing a solution clean and going to bin/debug folder: if you still see *.mdf files then that's the problem in your case too!
SOLUTION
The only solution that works well is to manually delete all *.mdb files in bin/debug from all projects in your solution (so Android project and all PCL projects) and then do a Rebuild.
Let me know if this helps!
For me "(" and ")" symbols were also causing the trouble, I was searching for weeks for this problem. Remove the "(" and ")" in the full path, do a clean build and de breakpoints are hit again.
In my case, xamarin was not hitting any breakpoint. Red color rings were shown instead of filled red circles, because there were some syntax errors not able to be pointed out by xamarin, since I think solution build was not up to date, even I was able to run the app surprisingly. So I cleaned and build the solution, and it pointed out errors and relevant warnings after that. I fixed those, and ran the project. I was able to debug successfully after that!
If once the project launches on the device VS reverts to the standard editing mode (no debug options enabled in the menu) i.e. the debugger is not attached; check Project Properties > Android Options > Enable developer instrumentation is checked. For me the setting was disabled (most likely checked into source control after a release).
Use "Visual Studio for Mac" (Preview at the moment but works) instead of "Xamarin Studio". This fixed the problem for me. Breakpoints are working even in my PCL projects! Another thing... I had to change "project.json" (JSON format) to "packages.config" (XML format) when changing from "Xamarin Studio" to "Visual Studio for Mac".
I am having great problems running the application in the debugger from Visual Studio 2008.
When I'm using vshost.exe, it says:
And when vshost.exe is turned of, it simply states:
Interesting thing about it is that when i do use vshost, debugger is actually started and breakpoint is hit on the first line of the Main().
I tried:
rebuilding the project(s)
removing .ncb, .suo, .user for the projects
repairing Visual Studio 2008
changing the build architecture for the project
... no help there...
Any experience in (trouble)shooting that?
More info: some projects DO work, and one that I have to work on, does not.
I have some ideas such as:
trying to create NEW project, add thing by thing to it and see at what point it will start to miss behave
work it other way around, delete project by item by item to see when it will (if it will) be working OK again.
EDIT (for google, as I see that there are many similar questions on the web):
Errors:
Error while trying to run project: Unable to start debugging.
and
Error while trying to run project: Unable to start program '....\PlayKontrol.exe'
Try upgrading your Visual Studio to Service pack 1, if you haven't already.
Did you restarted your computer? You never know how windows will react to that :).
Also be sure there aren't any keys stuck, like the ctrl or windows key.
Note that the key does not have to be visually stuck, it can be stuck for visual studio and not for the explorer.
The most common source of sudden problems like this is corruption of one of the data files that vs uses to cache information between builds.
You've tried a clean build, but this won't delete everything. A real clean build is: quit vs, delete bin, obj, debug, release folders, delete all generated files in the root - primarily ncb. Do the same for any locally built libraries that you're project references.
The easiest way to do this is if you have the code in source control, as you can rename away your entire code folder and then force a get of all the source.
You often need to do all of these things in one hit to clear the problem.
Less frequently, a reinstall of vs will sort things out (although this sounds unlikely in your case if it is only one project that breaks)
Also think carefully about anything you might have installed just prior to it failing... And remember that some install effects may not occur until the next reboot so it could be days ago. A particular cause of this are automatic windows updates and trial versions of things like the vs 11 beta.
You might try running the application from outside of VS, but have a line of code that looks like this: Debugger.Launch(); where you want your first breakpoint.