Skip to main content

Visual Studio debugging tips and tricks

Continui seria de posturi (1, 2, 3, 4) despre debug cu un post despre tips and tricks.
Daca in posturile precedente am vorbit despre cum se face debug in Visual Studio in functie de diferite cazuri, astazi vreau sa va prezint cateva tips and tricks din aceata zona.

Make Object Id
Prin acesta functionalitate putem sa facem tracking la un obiect chiar daca am iesit in afara blocului unde a fost declarat. Trebuie sa mentionez ca acest lucru se poate face doar cu reference type. Din fereastra de "Watch" trebuie sa dati click pe variabila pe care o aveti deja adaugata si sa selectati "Make Object ID". In urma acestei actiuni. In urma acestei actiuni o sa observati ca apare o noua variabile cu un nume de genul #1, iar valoarea o sa fie terminata cu "{1#}". Si dupa iesirea din blocul unde erau declarate si folosite, acestea o sa ramana in continuare active.

Immediate Windows
Aceasta fereastra poate sa fie extrem de utila cand este nevoie sa verificam anumite expresii sau sa executati anumite metode. Tot in aceasta fereastra puteti sa afisati/setati si valoarea unei variabile. Aceleasi lucruri se pot face si din Watch Window.

Run to cursor
Prin intermediul acestei functionalitait puteti sa sariti automat la linia de cod unde este cursorul fara sa tot apasati F10 si F11 si fara sa executati codul pana la linia respectiva. Odata ce v-ati pozitionat cursorul pe linia pe care doriti puteti sa dati click dreapta si sa selectati "Run to cursor" sau sa folosti scurtatura "Ctrl+F10".
Breakspoints features
Pe langa a avea un breakpoint in cod puteti sa ii setati diferite conditii sau diferite actiuni. De foarte multe ori se uita de aceasta functionalitate si se tot apasa F10 pana cand ajungeti pe cazul dorit. Acest lucru se poate foarte usor folosind condtiile care se pot atata unui breakpoint.
Un alt lucru destul de dragut care se poate face aici e definirea unei actiuni custom cand un breakpoint este lovit. De exemplu afisarea unui mesaj in fereastra de debug sau executarea unui MACRO. Despre aceste lucruri am vorbit deja in posturile precedente.

Debbuger.Break()
Sunt cazuri cand pe o anumita linie de cod vreti sa omorati aplicatie (break it). Acest lucru se poate face apeland "System.Diagnostics.Debuger.Break()". Atentie, acest lucru merge si in release mode. Pentru a verifica daca sunteti in debug este nevoie sa apelati proprietatea "System.Diagnostics.Debugger.IsAttached".

Debug.Assert()
Foarte utila cand vreti ca in cazul in care aveti asserturi pe care vreti sa le verificati doar in debug. Daca vreti si in productie aceste asserturi sa existe puteti sa folosti Trace.Assert().

View-uri diferite pentru text in format XML/HTML/Text
Orice valoare de tip string pe care o vizualizati in fereastra de Watch Windows poate sa fie vizualizata in diferite moduri. Clieck dreapta pe value si o sa vedeti ca puteti schimba modul de vizualizare (Text, XML sau HTML).

Schimbare valori la orice valoare on the fly
Odata ce sunteti cu mouse-ul deasupra unei valori, iar fereastra care contine valoarea in sine s-a afisat, puteti fara probleme as ii schimbati valoarea din aceastra fereastra fara nici o problema.

Atasare la un debugger la runtime
In cazul in care doriti ca sa fortati userul sa se ataseze la un debugger un anumite conditi, puteti sa faceti acest folosind "System.Diagnostics.Debugger.Launch()". In urma acestui apel userului o sa i se ceara sa selecteze un tool pentru debugging la care procesul nostru sa se lege.
In mod normal codul care face acesta actiune arata in felul urmator:
#if DEBUGi
f (!System.Diagnostics.Debugger.IsAttached)
{
    System.Diagnostics.Debugger.Launch();
}
#endif

Exista nenumarate tips and trick-uri pe partea de debug. Ce alte tips and tricks vi se pare foarte utile in aceasta zona?

Comments

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too