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

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

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.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…