Visual Studio - How to see the source code of .NET framework

Every time when I’m installing Visual Studio one a clean computer I have problems remembering the steps that need to be done on Visual Studio to see the source code of the .NET framework.

In the next lines we will look over the steps that need to be done. Next time when I will need to make this configuration I will come back to this post.

We need to go in Visual Studio menu, under Tool->Options and select the Debugging tab. In the general node we will need to check/uncheck the following options:

• Uncheck the “Enable Just My Code (Managed only)”
• Uncheck “Require source files to exactly math the original version”
• Check “Enable source server support”

In this moment we are almost done, the only think that we need to do is to double check under Symbols node that “All modules, unless excluded” is checked. In general I prefer to create a custom path where the symbols are downloaded.

While you are debugging, if you have any kind of problems loading this symbols, go on the call stack, right click on the stack and check if “Symbol Path” is selected in the “Load Symbols From”.

First time when you will debug after these changes, you will notify the application will run slower, because pdb files are downloaded.

Good luck!

Read More

New Unit Tests features of Visual Studio 2012

Visual Studio 2012 was already lunched some time ago. A lot of new feature were introduce with this new version. Some changes from Visual Studio 2012 are big and from some point of view, the difference between the old version of Visual Studio and the new one are like the difference between Windows 8 and Windows 7.

 I think that a lot of developers already played a little with this new version of Visual Studio. The first thing that you notify after installing it is the time that is necessary to load the new Visual Studio – that is very low. The second thing is the new UI, that is Metro like.

One zone where Visual Studio 2012 made a big step forward was Unit Testing. A lot of new feature were introduce in this area that not only increase the productivity of the developer, but also increase the quality of the code. In the next part of the post we will discover what are the main new features that were introduce from the unit testing perspective.

Run tests after each build

In the old version of Visual Studio, we didn’t have a build in mechanism to run unit tests after each build. Because of this we had to click on “Run All Tests” each time when we build the solution. This could be annoying after a while. Visual Studio 2012 already has this feature build in and with only one click we can activate or deactivate this feature.

All the tests run in background, without bothering us.

Debug/Run tests from direct from code

How many time you had to go to the Test Explorer window to be able to run your current test. From now one, Visual Studio 2012 have a shourcut in the menu that will run the test that are selected in the code.

Group and run unit test based on the category

From now one we can add one or more categories to our unit test. This attribute can be added not only to each test in part but also to the unit test class. Using this feature we can run unit tests only from a specific category. This is a great feature when not only on the developers’ machine, but also on the build machines.

To be able to run the unit tests that have a specific category from command line we need to specify the TestCaseFilter option:

Vstest.console.exe myFooProject.dll 
   /TestCaseFilter:”TestCategory="Atomic"

Assert.ThrowsException

Until now, if we had a unit test that would check if a method throws an expected exception; we would have to decorate our method with an attribute. But this is not the best solution, because there were cases when we could not determine precisely the source of the exception.

In this moment this feature is available only for Windows Store Application. We hope that this new feature will be also available for other type of projects also.

Smart unit test discovery

The algorithm that is used to discover new unit test was improved. In this moment the new unit tests are discover extremely fast. We don’t need to rebuild the solution and wait until the new unit tests are discovered by Visual Studio.

Integration with JavaScript

Using a plugin like Chutzpah Test Adapter, we are able to run unit test written in JavaScript and run them in Test Explorer. Not only this, but we can run test written in C# and JavaScript in the same time. In this way we can run the entire test as one thing. The only thing that is necessary to be done is to install Chutzpah Test Adapter and use a unit test package for JavaScript like qunit.

Unit testing is a lot easier with this new version of Visual Studio. These are only a part of the new features that Visual Studio 2012 brought to us. You can try it and discover by yourself these new great features.

Read More

Custom configuration files for each developer machine

I think that all of you use configuration files. When we are working with a complex project, where many developers need to configure their environment in a way to have a custom configuration, there are cases when they install some application in different locations for example, or they have the SQL server with a different name.
What we can do with these cases? In a perfect world we would not have this problem, but for example a part of the team want to use the SQL Azure and another part of the team want to use their own SQL server instance.
When the configuration is in the web.config or in the app.config, Microsoft offer to us a very nice solution. We can have different configuration for each developer (on their local machine). Each time we will rebuild the solution, the configuration file will be regenerated.
This feature is supported from Visual Studio 2008 2010, but is not well known by all developers. In the next part of the post we will see how we can configure our project to support this functionality.

• First step that need to be done is to remove the web.config file from TFS. This simple trick can be done if you follow the next steps:
• Select your project, right-click on it and unload it (“Unload Project”)
• Select your unloaded project, right-click on it and open with the XML editor (“Edit [ProjectName]”)
• Search all the node named “Content” where the “Include” attribute point to the configuration files
• Comment all the “DependentUpon” nodes that are under these nodes

• Save the file and reload the project (right-click on the project and click on “Reload Project”)

<Content Include="Web.Debug.config">
  <!--<DependentUpon>Web.config</DependentUpon>-->
</Content>
<Content Include="Web.Release.config">
  <!--<DependentUpon>Web.config</DependentUpon>-->
</Content>

• Duplicate the configuration file and rename the copy to “Web.base.config”

• Remove the web.config file from TFS

In this moment we excluded the configuration file from TFS. Also we create a base configuration file that will be used by the system as the original configuration file.
After this step you can reopen the project with the XML editor and uncomment the “DependentUpon” nodes.
Now, we need to specify to the build to recreate the configuration file at each build using the base configuration file and the custom configuration files that can be found in the project. Next steps need to be done to be able to define this functionality:

• Add a file to your project named[YourProjectName].wpp.targets

• Add the following content to it:

Visual Studio 2010:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <UsingTask TaskName="TransformXml"
               AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>  
    <Target Name="CopyWebConfig" BeforeTargets="Build;Rebuild">
        <Copy SourceFiles="Web.base.config"
              DestinationFiles="Web.config"
              OverwriteReadOnlyFiles="true"
              SkipUnchangedFiles="false" />
    </Target>
    <Target Name="CustomTarget" BeforeTargets="BeforeBuild">
        <Message Text="Transforming: Web.$(Configuration).config" Importance="high" />
        <TransformXml Source="Web.base.config"
                      Transform="Web.$(Configuration).config"
                      Destination="Web.config" />
    </Target>
</Project>

Visual Studio 2012:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <UsingTask TaskName="TransformXml"
               AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>  
    <Target Name="CopyWebConfig" BeforeTargets="Build;Rebuild">
        <Copy SourceFiles="Web.base.config"
              DestinationFiles="Web.config"
              OverwriteReadOnlyFiles="true"
              SkipUnchangedFiles="false" />
    </Target>
    <Target Name="CustomTarget" BeforeTargets="BeforeBuild">
        <Message Text="Transforming: Web.$(Configuration).config" Importance="high" />
        <TransformXml Source="Web.base.config"
                      Transform="Web.$(Configuration).config"
                      Destination="Web.config" />
    </Target>
</Project>

This file is necessary in the build process to create the configuration file based on the base file and our custom configuration file that we will add.
Because each build configuration is custom for each machine, we can add many build configurations we want. For each build configuration we can add a custom configuration file. Let’s see how we can add a build configuration and to generate a configuration file for our custom build:

• Go to “Build” menu from Visual Studio and select “Configuration Manager”
• On the “Active solution configuration” combo-box select “New” and create a new build configuration with any name you want. I recommend a name like [username.machinename]
• Close the “Configuration Manager” windows
• Right-click on the configuration file from your project and click on “Add Config Transform”
• Success, the system created our custom configuration file.  Don’t forget to NOT check-in this configuration file to the TFS. Also the “Add Config Transform” will be active only when there are some new changes in the “Configuration Manager”.

From now on when we will run our application using our custom configuration for the build, the configuration file will be recreated using the base configuration and our custom configuration file, specified for our custom build.
In this way we can have custom configuration on each developer machine without any kind of problemes.

Read More

Serie de turoriale despre debug in Visual Studio

Mai jos puteti sa gasiti link-uri spre o lista de posturi personale despre cum putem sa facem debug in Visual Studio:

1. Base Visual Studio debugging functionalities
2. Debugging multithreaded applications in Visual Studio
3. Some cool stuff debugging with Debugger Canvas
4. New debugging functionalities in Visual Studio 2012
5. Visual Studio debugging tips and tricks

Daca aveti si alte propuneri, va rog sa imi lasati un comment.

Read More

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?

Read More

New debugging functionalities in Visual Studio 2012

Continui seria de posturi (1, 2, 3) cu noile functionalitati de debug din Visual Studio 2012. In acest post o sa vorbim despre ce a adus nou Visual Studio 2012 pe partea de debug.
In cazul in care lucrati cu aplicatii web in noul Visual Studio o sa vedeti ca langa butonul de Debug a aparut o lista cu browerele sub care doriti sa rulati aplicatia. Acest feature este destul de util, mai ales ca nu mai este nevoie sa ne instalam tot felul de plugin-uri care faceau acest lucru.

 Tot acest buton ne permite sa rulam sa pornim cu un sigur click aplicatia noastra in mai multe browsere. Pentru acest lucru este nevoie sa dati click pe "Browse With...". In aceasta locatie puteti selectati mai multe browesere pe care sa le setati ca default. In cazul in care doriti puteti seta si dimensiunea ferestrei.

O alta noua functionalitate este pe partea de profiling, care ne permite sa identificam zonele de cod lente. Aceasta suporta in momentul de fata si Metro Applications. Partea de profiling putea sa fie gasitia si pe Visual Studio 2010.
Pe partea de UI, apare o noua functionalitate care ne permite sa  facem debug pe partea de UI. Nu neaparat debug, ci mai degraba o diagnosticare a UI care ne permite sa vedem din ce cauza unele elemente se afiseaza gresit. Din pacate nu am reusit sa pornesc acest tool pe masina mea.
 Cam astea ar fi legat de noile funcționalitati de debug din Visual Studio 2012 pe care le-am gasit si care mi s-au parut importante. Pe partea de profiling au aparut noi functionalitati care ne ajuta pe partea de debug, dar nu sunt legate de actiune de debug propriu-zisa.  Voi ati gasit si altele?

Read More

WTF - Package Load Failure - Microsoft.VisualStudio.TeamFoundation.VersionControl.HatPackage, Microsoft.VisualStudio.TeamFoundation.VersionControl

In cursul zilei de azi am avut parte de o experienta destul de neplacuta. De doua ori mi s-a restartat PC-ul fortat in timp ce Visual Studio se incarca. O sa spuneti si ce daca, asa am zis si eu, dar am avut o surpriza neplacuta sa ma trezesc cu niste erori destul de urate.
Dupa ce pornit din nou sistemul de operare si Visual Studio am vrut sa accesez din Team Explorer Source Control-ul dar m-am trezit ca acest lucru nu mai este posibil. Puteam sa vad lista de build-uri, documentele de pe SharePoint si orice altceva, mai putin sa accesez Source Controler-ul. Am primit o eroare destul de urata, asemanatorare cu urmatoarea:

... Package Load Failure - Microsoft.VisualStudio.TeamFoundation.VersionControl.HatPackage, Microsoft.VisualStudio.TeamFoundation.VersionControl ...

WTF, de unde pana unde, nici nu stiam de unde sa o iau. Am incercat restore la OS la o versiune precedenta dar la fel. Am incercat sa reinstalez Team Explorer-ul dar fara nici un rezulvat. Pana la urma am ajuns in cache-ul de la Team Foundation, unde a fost nevoie sa sterg fisierul "VersionControl".

c:\Users\[someUser]\AppData\Local\Microsoft\Team Foundation\3.0\Cache\ VersionControl.config

Odata ce l-am sters lucrurile pareau sa revina la normal si am putut din nou sa accesez source controler-ul.
Din nou am avut o surpriza neplacuta cand am incercat sa deschid solutia pe care lucram. Nici unul din proiectele din solutie nu le putema deschide. Nu avea importanta ca era un proiect standard de .NET 4.0, sau de SL 4.0. Nici unul nu se putea incarca, iar urmatoarea eroare se afisa pentru fiecare proiect din solutie care se incarca:

A project with that name is already opened in the solution.

Din nou WTF, acest lucru se intampla si cand doream pe o solutie goala sa adaug un proiect. A fost nevoie sa fac repair la VS 2010 SP1, iar apoi sa reinstalez SL 4.0 Tools, iar apoi din nou repair la VS 2010 SP1.
I did it, solutia din nou se incarca fara probleme si totul a revenit la normal.
Sper sa nu aveti si voi aceleasi probleme.

Read More

Some cool stuff debugging with Debugger Canvas

Continui seria de posturi (1, 2) despre cum sa facem debug in Visual Studio cu un post dedicat Debugger Canvas.
Cati dintre voi ati apucat sa o folositi intr-un mediu real? Mai mult ca sigur v-ati jucat cu ea, dar ati reusit sa o folositi mereu? Eu va spun sincer ca nu. Sunt cazuri cand poate sa fie foarte utila, dar in unele situatii, cand vrem sa facem un debug simplu e mult prea complexa.
Acesta este un tool free, care poate sa instalat in Visual Studio. Il puteti download din urmatoarea locatie http://download.microsoft.com/download/5/A/7/5A7FB2E7-5720-4739-BDDE-28A684C5B291/Microsoft.DebuggerCanvas.vsix si daca ma intrebati pe mine, este unul din tool-urile care nu poate sa lipseasca din Visual Studio.
Cand mi se pare extrem de utila? In momentul in care este nevoie sa facem debug intr-un mediu cu multe thread-uri care ruleaza simultan sau cand avem parte de recursivitate. In aceste cazuri este extrem de usor sa urmarim valorile  la fiecare field sau variabila din call stack.

Odata ce ati instalat aplicatia, aceasta o se seataza automat ca si default debug tool. Puteti oricand sa o dezactivati din "Debug->Debugger Canvas". Totodata aveti cateva optiune la acest tool pe care le puteti schimba din "Tools->Options - DEbugger->Debugger Canvas". Ajunge cu teorie, sa vedem in practic ce putem face.
Intr-o fereastra separat, tot callstack-ul vi se afiseaza sub forma unor ferestre inlantuite. Este extrem de usor sa vedem de unde vine apelul, putand naviga in orice moment prin call stack si sa vedem ce valori au variabilele.

O functionalitate extrem de utila este lista de variabile locale la care se poate face snapshot. Nu mai este nevoie sa notam noi vechile valori. Putem direct sa facem un snapshot si sa ne continuam procesul de debug. Pentru fiecare snapshot se afiseaza si locatia de unde s-a facut. In orice moment cu daca faceti click dreapta o sa vi se afiseze un meniu care va permite sa adaugati notite sau sa salvati sesiune de debug ca un XPS ori sa o trimiteti pe email. Partea de save/send va spun sincer nu am folosito niciodata, cel mai des cred ca folosesc snapshot-ul.

Este bine de mentionat ca in momentul in care folositi Debugger Canvas, toate scurtaturile sau optiunile care le aveati intr-un debug clasic raman available, tot ce se schimba este modul in care vizualizati resultatele.
Un alt feature extrem de util este cand aveti mai multe thread-uri pornite si vreti sa vedeti in paralel call stack-urile. In mod normal acestea se refolosesc, dar daca mergeti la options si dezactivati optiunea "Reuse Bubbles When Content is the Same" o sa vedeti pentru fiecare thread in parte un alt set de ferestre.

Odata ce ati terminat procesul de debug, fereastra o sa ramana deschisa, cu toate datele care s-au afisat. Acest lucru putand sa fie extrem de util.
Cam asta ar fi despre Debugger Canvas. Aduce cateva feature dragute, care ne pot ajuta si fac uneori diferenta. Ce parere aveti de acest tool? L-ati folosii?

Read More

Debugging multithreaded applications in Visual Studio

In postul precedent am povestit putin despre cateva lucruri de baza cand facem debug in Visual Studio. Astazi o sa continuam aceasta discutie si o sa vedem cum putem face debug intr-un mediu multi-thread si multi-processor.
Cand lucram cu mai multe thread-uri, fereastra "Threads" devine cea mai buna prietena a noastra. Prin intermediul acesteia, cand aplicatia ajunge la un breakpoint putem sa vedem toate thread-urile active in procesul nostru. Pentru fiecare thread, putem sa vedem numele acestuia, ID-ul prioritatea si nu in ultimul rand call stack-ul pentru fiecare thread in parte (numele la coloana este "Location"). De foarte multe ori callstack-ul ne ajuta foarte mult nemaifiind nevoie sa selectam cate un thread in parte pentru a vedea callstack-ul.
In momentul cand suntem intr-un breakpoint sa nu uitati ca restul thread-urile ruleaza in continuare. In dreapta acestei ferestre avem un buton "Freeze" prin intermediul caruia putem sa facem freeze la toate thread-urile din procesul nostru. Nu odata mi s-a intamplat ca pana sa investighez codul care rula dintr-un thread, unul sau mai multe thread-uri s-au terminat de executat, iar problema pe care o aveam nu o mai puteam reproduce. Cand un thread este selectat din lista, Visual Studio o sa incerce sa va dupa la codul care se ruleaza pentru thread-ul vostru.

O fereastra asemanatoare exista si pentru procese. In mod normal o sa fiti legati la un sigur proces, caz in care o sa aveti un singur proces in lista. 2 sau mai multe procese pot sa fie active cand aveti mai multe procese selectate de a rula la RUN sau cand va atasati manual la alte procese. 
Toate modulele (assembly-urile) care sunt incarcate intr-un anumit moment pot sa fie vizualizate din fereastra Modules. Aceasta fereastra este folositoare daca aveti probleme cu versiune de assembly sau nu stiti exact ce assembly se incarca si din ce locatie. Aceasta fereastra poate sa deschisa din "Debug->Windows->Modules".

Cand executati codul step cu step si aveti mai multe thread-uri pornite sa nu uitati ca restul thread-urilor ruleza normal daca nu ati facut freeze. Iar in cazul in care un alt thread ajunge la un breakpoint, atunci o sa va intrati pe thread-ul respectiv. Puteti specifica pe un breakpoint pe ce thread sa se activeze (in postul precedent am discutat despre acest lucru).
In cazul in care aveti mai multe thread-uri puteti sa folositi fereastra de "Parallel Stacks" fara nici o problema, chiar daca nu folositi librarie de paralle library. Aceasta va afiseaza un stack pentru modul in care thread-urile au fost create si ce thread pe care il asteapta.

Cand faceti debug incercati ca numarul de thread-uri pe care le aveti pornite sa fie cat mai mic (3-4). Daca o sa aveti prea multe thread-uri pornite, procesul de debug o sa fie destul de complex.
In urmatorul post o sa discutam despre Debugger Canvas.

Read More

Base Visual Studio debugging functionalities

Cred ca un programator intr-o zi normala de lucru, are nevoie cel putin odata pe zi sa faca debug la cod. Visual Studio are extrem de multe functionalitati care pot sa fie utile in procesul de debug. Din pacate, dupa o perioada de timp uitam de toate feature-urile pe care le avem la dispozitie. In acest post o sa incerc sa trec peste o parte din aceste feature. In prima parte a postului o sa folosesc Visual Studio 2010, iar Visual Studio 2012 o sa folosesc doar pentru cele specifice la Visual Studio 2012.
In mod normal pentru a putea face debug trebuie sa rulam proiectul nostru in dubug. Acest lucru se poate face folosind tasta F5 sau apasand butonul "Start Debugging" din meniul "Debug". In cazul in care procesul nostru deja ruleaza este nevoie sa ne atasam la proces. Acest lucru se face din meniu "Debug-> Attach to Process" sau prin combinatia de taste "Alt+Ctrl+P". 

Puteti sa va atasati la unul sau mai multe procese. In cazul in care nu gasiti procesul in lista, inseamna ca acesta ruleaza sub un alt user sau in alta sesiune. Pentru a putea vedea si acest procese este nevoie sa selectati checkbox-ul "Show processes from all users" sau "Show processes in all sessions". In cazul in care proiectul la care va atasati nu este 1 la 1 cu versiunea pe care o aveti deschisa s-ar putea ca sa nu puteti intra in toate brakepoint-urile pe care le adaugati. In cazul in care adaugati brakepoint-uri si observati ca dupa ce v-ati atasat la proces, acestea au un cerculet rosu si cu un semnul exclamarii langa ele, inseamna ca sursa si versiunea la aplicatie la care faceti debug nu este 1 la 1. Pentru a putea totusi sa faceti debug este nevoie sa debifati optiunea "Require source files to exactly match the original version" din "Tools->Options".

Aceiasi optiune, pentru a accepta ca codul din solutia deschisa sa fie diferit fata de cel care ruleaza poate sa fie gasit data dati click pe breakpoint si selectati optiunea "Location". In aceasta fereastra o sa puteti selecta locatia unde breakpoit-ul este adaugat.

Daca tot am inceput cu optiunile pe care le avem pe un breakpoint, o sa continui si cu restul. Urmatoarea optiune este de adaugare de conditii la breakpoint. Pe baza acestor conditii, putem seta daca aplicatia sa se opreasca la un breakpoint sau nu. Putem sa adaugam orice fel de conditie, iar vestea buna ca avem intelliSense in acest loc, a.i. ne este foarte usor sa definim una sau mai multe conditii legate prin &&, ||. Optiunea de "Has changes" este foarte utila cand vrem ca sa intram in breakpoint cand valoarea conditiei s-a schimbat. In acest caz valoare nu trebuie sa fie obligatoriu de tip boolean.

Urmatorul setup pe care il putem face la un breakpoint este sa setam un contor pentru hits counter. By default, la fiecare atingere a unui breakpoint cand conditia este sadifacuta, aplicatia o sa se opreasca la breakpoint. Dar sunt cazuri cand vrem sa specificam doar la primele 3 sa se opreasca sau cand aceasta valoare este mai mare decat 10.

In cazul in care vrem ca un breakpoint sa fie activ doar pe anumite thread-uri sau doar pe anumite procese (cazul in care suntem atasati la mai multe procese) putem sa ne folosim de urmatoarea optiune care apare in meniul unui breakpoint - "Filter". Putem sa setam ca un breakpoint sa intre doar pe un thread cu un anumit id sau nume sau doar daca ruleaza pe o anumita masina. In exemplul de mai jos, doar in cazul in threadul se numeste "CustomThread"  si rulam pe o masina cu numele "W8" breakpointul o sa fie activ.

Urmatorul lucru pe care il putem seta este un macro care sa se execute cand breakpointul este lovit sau sa afisam un anumit mesaj. Pana in momentul de fata nu am avut nevoie de aceasta functionalitate, dar ce mi se pare interesant la ea este ca putem seta ca executia codului sa se continue, dupa ce s-a executat actiunea custom din macro sau s-a afisat mesajul nostru, Un macro destul de interesant pe care l-am vazut in schimb era generarea automata a unui fisier de dump de fiecare data cand breakpointul era lovit.
Fiecarui breakpoint ii pot sa fie atasate unul sau mai multe label-uri. Acestea ne pot ajuta sa grupa breakpoint-urile in functie de anumite date. Pentru a putea vedea toate breakpoint-urile dintr-un proiect este nevoie sa deschidem fereastra "Breakpoints" din meniul "Debug->Windows->Breakspoints" sau folosind scurtatura "Ctrl+Alt+B". In aceasta lista putem in orice moment sa activam/ dezactivam un breakpoint, putem sa cautam un anumit breakpoint. Cea mai interesanta functionalitate mi se pare cea de import si export. Putem sa exportam o lista de breakpoint-uri pe care apoi o putem importa pe un alt calculator sau sa o folosim mai tarziu. Aceasta lista se salveaza sub forma unui fisier XML.

Cand suntem intr-un anumit breakpoint, fereastra "Imediate Windows" este extrem de utila pentru a putea executa cod scris la runtime. Trebuie sa avem grija ca nu putem sa scriem lambda expressions si sa le executam la runtime.
In mod normal cand suntem in debug, aplicatia noastra nu o sa se opreasca cand se arunca excepții care sunt mai tarziu prinse de catre codul nostru. Sunt insa cazuri cand vrem sa prindem si acest gen de exceptii. Pentru acest lucru avem la dispozitie fereastra "Exceptions" din "Debug->Exceptions" sau scurtatura "Ctrl+Alt+E". Putem selecta ca la anumite exceptii codul scris de noi sa se opreasca. In exemplul de mai jos pentru orice exceptie de tip AccessViolationException aruncata, care chiar daca exceptia este prinsa de sistemul nostru, aplicatie se opreste si putem face debug cand aceasta este aruncata.

Nu uitati ca in aceasta fereastra aveti disponibila funcionalitatea de cautare by name a unui excepti. Aceasta este extrem de utila cand vrem sa setam un comportament custom pentru o anumita exceptie, deoarece numarul acestora este foarte mare.
In momentul in care aplicatia noastra se afla intr-un anumit breakpoint, avem la dispozitie call stack-ul pentru a putea sa vedem de unde a fost apelat codul nostru. Folosind call stack-ul ne putem plimba pe acesta si sa vedem valoarea variabilelor din fiecare locatie. In fereastra "Locals" se pot observa toate variabilele locale, in functie de unde o sa fim pe stack o sa putem vedea variabilele pentru locatia respectiva din stack.
Fereastra "Autos" uneori poate sa fie extrem de utila, dar trebuie sa intelegem foarte bine ce afiseaza aceasta. In cadrul acestei ferestru o sa fie afisate variabilele, expresiile sau parametri care s-au modificat recent si pe care sistemul considera ca sunt relevanti. In cadrul ferestrei de "Watch" putem sa afisam orice expresie si sa urmarim cum se schimba aceasta valoare in timp ce face debug.

Pentru orice variabila, in debug, putem sa vedeam valoare acesteia, sa adaugam sau sa modificam aceasta valoare.
Cam atata ar fi despre base debugging stuff in Visual Studio. In urmatorul post de maine o sa vorbim despre multi-thread debugging, iar apoi despre Debugger Canvas.

Read More

How to create a setup package for a Metro Application in Windows 8 using Visual Studio 2011

Odata cu Windows 8 si aplicatiile de tip Metro App, lucrurile au inceput sa se schimbe nu doar cum o aplicatie trebuie sa se comporte, sa arate si sa reactioneze ci si cum facem deploy-ul. Astazi vreau sa vorbim cum putem sa generam un pachet (setup package) pentru aplicatia noastra pentru a putea sa fie instalata m-ai tarziu pe o masina cu Windows 8. Necesitatea creari unui pachet apare destul de usor. Clientul ne poate cere intr-un anumit moment sa ii trimitem aplicatie pentru a vedea cum arata si cum functioneaza sau echipa de testare are nevoie de aplicatie pentru testare. Pentru oricare din aceste cazuri, un zip cu codul sursa nu este o solutie. Persoanele la care ajunge acest zip s-ar putea sa nu fie tehnice si nici nu vrei sa trimiti codul sursa la orice persoana. Output-ul generat in bin nu o sa ajute deloc. Microsoft ne ofera o solutie la aceasta problema - crearea unui pachet a aplicatiei noastre. Odata creat acesta poate sa fie instalat pe orice masina cu Windows 8. Dupa ce am creat aplicatia, este necesar sa selectam proiectul principal (cel pe care il folosim sa rulam aplicatia), iar din meniul care se afiseaza cand dam click dreapta pe acesta sa selecta "Store -> Create App Package" (la acesta optiune se poate ajunge si din meniu "Project -> Store -> Create App Package").

Dupa acest pas aveti doua optiuni, sa creati un pachet pentru store-ul de Windows 8 sau un pachet care sa fie folosit local. In cazul nostru, avem nevoie de a doua optiune. In acest moment este bine de mentionat ca acest pachet poate sa fie instalat doar pe sistemele de operare cu Windows 8 Enterprise sau cele care au o licenta pentru dezvoltare.

In urmatorul pas o sa fie necesar sa introducem locatie unde se v-a genera pachetul, versiunea aplicatiei si pentru ce platforme vrem sa cream pachetul (x86, x64, ARM, any CPU). La acest pas mi-a placut functionalitatea de auto-increment la versiunea aplicatiei. Ne poate salva de cateba batai de cap.

 Odata datele introduse pachetul se poate crea apasant butonul "Create", cand pachetul se genereaza automat. Pachetul odata generat o sa contina un fiser bat cu numele "Add-AppxDevPackage.bat" care poate sa fie rulat pe orice masina atat din linie de comanda cat si separat. Singurul lucru care trebuie facut la instalarea pachetului este sa rulam acest bat ca si administrator (cu drepturi elevate). Procesul de creare si deploy a unui pachet este destul de simplu, poate sa fie inclus si intr-un build automat a unui MSBUILD si este tot de ce am avea nevoie pentru un deploy simplu intr-un mediu de testare sau un demo pentru client.

Read More

How to change version of our solution assemblies

Am vazut cateva persoane care au ajuns pe blog cautand cum se face versionarea unui assembly. O sa prezint cea mai simpla metoda pentru a putea face versionarea unui proiect.
By default, versiunea unui proiect din solutia noastra poate sa fie gasita in fisierul AssemblyInfo.cs, care se gaseste in Properties. Daca vrem sa schimbam versiunea unui assembly, trebuie sa facem update la atributele AssemblyVersion si AssemblyFileVersion.

[assembly: AssemblyVersion("1.2.3.4")]
[assembly: AssemblyFileVersion("1.2.3.4")]

Sunt insa momente cand vrem sa controlam versiunea la toate assembly-urile generate de catre solutia noastra. Pentru a putea face schimbarea versiunii dintr-un singur loc, fara sa facem update la fiecare proiect in parte, putem sa extragem aceste doua atribute intr-un fisier separat. Acesta ar avea urmatoarea forma:

using System.Reflection;
[assembly: AssemblyVersion("1.2.3.4")]
[assembly: AssemblyFileVersion("1.2.3.4")]

Numele la acest fisier de obicei este VersionInfo.cs. In fiecare proiect acesta poate sa fie adaugat ca si fisier link-at la solutie (Add file as link). In acest fel, este nevoie sa modificati intr-un singur loc numele la fisier. Cand se va face build, fiecare assembly o sa fie marcat cu versiunea care este specificata in fisierul nostru.

Read More

Use LINQ to get items of specific type

Ma uitam peste un cod scris de mine in urma cu cateva zile si am gasit urmatoarea linie de cod:

var fooCollection = items.Where( x => x is Foo).Select(x => x as Foo);

In cazul in care vrem sa extragem elementele dintr-o colectie care sunt de un anumit tip putem sa folosim metoda OfType. Aceasta metoda returneaza toate elementele din colectie de un anumit tip. Colectia pe care o returneaza o sa contina doar elemente de tipul specificat de catre noi.
Daca rescriu linia de mai sus o sa obtinem:

var fooCollection = items.OfType<Foo>();

Colectia returnata o as fie de tipul dupa care filtram datele. In exemplul dat de mine, rezultatul returnat o sa fie de tip IEnumerable. Astfel incat nu mai este nevoie sa facem nici un fel de conversie.
Mai jos gasiti un link pagina MSDN care descrie aceasta functie:
http://msdn.microsoft.com/en-us/library/bb360913%28v=vs.110%29.aspx

Read More

How to deploy and debug remote on a Windows 8 tablet using Visual Studio

Si iata ca am ajuns in momentul in care putem sa testam aplicatii Metro pentru Windows 8 direct de pe tablete. Daca ati dezvoltat aplicatii pentru Windows Phone 7 pana acuma si ati facut deploy si debug pe device, trebuie sa stiti ca acest proces este destul de asemanator.
Cea ce s-a schimbat este modul in care conectati device-ul la calculator. Daca telefonul se conecta prin intermediul unui cablu, iar pe masina era "have to" sa aveti instalat Zune, pentru a face deploy si debug la o aplicatie pe o tableta cu Windows 8, tot ce aveti nevoie pe langa device este ca acesta sa fie conectat la retea. Tableta poate sa fie conectata la retea atat prin WiFi, cat si prin cablu de retea (depinde de ce model aveti).
Pentru a putea face deploy la aplicatie este nevoie ca sa instalati pe tableta Visual Studio 2011. Odata ce ati facut acest lucru in START o sa puteti gasi Remote Debugging Monitor (executabilul se numeste msvsmon.exe). Acesta trebuie pornit pe tableta si lasat sa ruleze. Prin intermediul acestuia o sa puteti face remote deploy si debug. Trebuie sa va spun ca fata de versiunea pentru VS 2008, cu care am lucrat acu 2 ani pe un alt proiect acesta a fost foarte mult imbunatatit, nu am avut nici o problema cu el.
Ca procesul de deploy sa fie cat mai simplu si deoarece in general cand facem deploy si debug suntem intr-o retea sigura va recomand ca dupa ce ati pornit Remote Debugging Monitor sa deschideti Tools->Options si sa selectati optiunea de "No Authentication" si sa aveti grija sa lasati bifata optiunea de "Allow any user to debug". Intr-o retea sigura daca lasati aceste optiuni active o sa va complicati putin viata, mai ales intr-un mediu corporate unde avem un Active Directory si toata povestioara.
De pe masina de development, pentru a putea deploy pe tableta trebuie sa specificati adresa IP a tabletei sau numele care ati dat la tableta in Visual Studio. Pentru a obtine IP-ul la tableta nu incercati sa cautati cmd.exe si sa executati ipconfig.exe, deoarece in acest moment nu aveti parte de cmd.exe. Ce puteti face este sa deschideti conexiunea curenta la retea si sa dati click pe details. Acolo o sa puteti gasi adresa IP.
Odata ce ati deschis Visual Studio 2011 impreuna cu solutia voastra, selectati proiectul de UI si dati click dreapta, iar apoi "Properties". In tabul "Debug", este nevoie sa selectati la "Target Device" valoarea "Remote Machine" - puteti sa folositi atat IP-ul sau numele la tableta. Va recomand sa folosti numele la tableta, deoarece IP-ul in general nu este fix. Debiti optiunea de "Use authentification" deoarece nu aveti nevoie de ea in acest moment.
In cazul in care vreti sa setati ca doar anumiti useri sa poate face deploy, va recomand ca in prima faza sa urmati pasii de mai sus, iar doar apoi sa incepeti sa restrictionati cine poate sa faca deploy si debug.
Va mai recomand sa selectati si optiunea "Always re-install my package", ca sa fiti siguri ca ultimele modificari ajung pe tableta.
Spor la deploy!

Read More

Visual Studio 2011 BETA - XAML error report problems

In cazul in care lucrati cu Visual Studio 2011 BETA si sa trezici ca build-ul va crapa, desi nici o eroare nu se afiseaza, una din cauze poate sa fie XAML gresit. In unele cazuri, VS nu ne raporteaza ca XAML este gresit si doar in momentul in care MSBUILD ruleaza apare eroarea. Problema este ca aceasta nu este afisata, singurul lucru care se intampla este ca procesul de MSBUILD ramane agata si chiar daca incercam sa il inchidem din task manager, o sa ne trezim ca apare aceiasi problema la urmatorul build.
Mesajul de eroare care se afiseaza nu are nici o legatura cu eroarea reala si ne v-a avertiza ca MSBUILD-ul nu poate sa stearga un assembly deoarece este folosit de un alt proces.
Greseala in XAML pe care eu avuto cand bug-ul s-a reprodus este urmatoarea:

x:Name={Binding Name}

Spor!

Read More

Manifest refereces file 'Bing.Maps.dll' which is not part of the payload.

In cazul in care ati inceput sa lucrati cu Visual Studio 2011 Beta si Windows 8 ati putut observa ca exista deja SDK pentru Bing Maps pentru Metro Style. Acesta se poate instala la urmatoarea adresa:
http://visualstudiogallery.msdn.microsoft.com/0c341dfb-4584-4738-949c-daf55b82df58
Dar s-ar putea sa va treziti cu o eroare destul de ciudata cand vreti sa adaugati o harta in proiect:

Manifest refereces file 'Bing.Maps.dll' which is not part of the payload.

Fiind beta, exista mici scapari. Ca sa rezolvati aceasta probleme schimbati 'Platform Target' pentru proiectul vostru din 'Any CPU' in 'x86' sau 'x64'. Dupa acest pas totul ar trebui sa functioneze fara nici o problema.
Spor.

Read More

Visual Studio 2010 extensions

Zilele acestea am fost constrans de un upgrade la OS care mi-a omorat masina sa instalez de la 0 toate aplicatiile. Mai jos o sa gasiti lista de extensii pentru Visual Studio 2010 pe care le folosesc:

• Code alligment - il folosesc cand am nevoie sa aliniez codul dupa un anumit caracter( de exemplu cand trebuie sa aliniez cateva linii de cod dupa '=').
• Indent Guides - traseaza linii verticale pentru fiecare nivel de intentare in parte.
• PowerCommands for Visual Studio 2010 -  mai multe comenzi pe partea de management la proiecte si soluții.
• Productivity Power Tool - cel mai mare plus care l-a adus pentru mine a fost fereastra de add/remove references.
• Spell Checker - face check la spelling pentru string-uri, comnent-uri si plain text.
• VSCommands 2010 - coloreaza diferit codul scris iar cand dam click dreapta pe un fiser/director/proiect/solutie ne ofera noi functionalitati precum: deschidere CMD cu path-ul setat in directorul curent, copy class, copy full path etc.

Enjoy!

Read More