18

Mam projekt demonstracyjny, który tworzy zespół i używa go. Mogę również debugować kod wstrzyknięty. Ale jeśli prowadzę zasięg, analizę lub profilowanie, to się liczy, ale chcę to zmierzyć.Pokrycie kodu, analiza i profilowanie dynamicznie generowanego kodu

Kod:

CSharpCodeProvider codeProvider = new CSharpCodeProvider(); 
ICodeCompiler icc = codeProvider.CreateCompiler(); 
CompilerParameters parameters = new CompilerParameters(); 
parameters.GenerateExecutable = false; 
parameters.GenerateInMemory = false; // debug enabled     
parameters.OutputAssembly = "DynamicCode.dll"; // if specified creates the DLL 
parameters.IncludeDebugInformation = true; 
CompilerResults results = icc.CompileAssemblyFromFile(parameters, "InjectedCode.cs.txt"); 

tworzę DLL, aby sprawdzić wygenerowany kod IL. Mogę debugować kod w VS. Ale kiedy uruchamiam zasięg, wygenerowany zestaw jest po prostu pominięty, jeśli korzystam z katalogu TEMP, lub jeśli wyprowadzam bibliotekę DLL (jak wyżej), NO FILE jest uwzględnione w zasięgu (a więc nawet w głównym zespole).

Po uruchomieniu profilowania widzę tylko wywołanie (odbicie), ale nic na temat wygenerowanego kodu. Kiedy wykonuję analizę (mam pewne błędy we wstrzykniętym kodzie, np. Nieużywane locale i analiza ofc dla wszystkiego), nie zgłoszono żadnych problemów z wstrzykniętego kodu. Wstrzykiwany kod:

namespace CodeInjection 
{ 
    public static class DynConcatenateString 
    { 
     public static string Concatenate(string s1, string s2){ 
      // System.Diagnostics.Debugger.Break(); // break here for debugger and also test comment output 
      int a = 1+2+3+4+5; // complicated math 
      int b = a+2; 
      int c = 0; 

      return s1 + " !"+b+"! " + s2; 
     } 
    } 
} 

Chciałbym użyć zasięgu, profilowania i analizy wygenerowanego kodu (głównie pokrycia).

Odpowiedz

1

Pokrycie kodu OK w VS 2012 nie ma pełnego wsparcia dla generowanego dynamicznie kodu.

Można run our analyze command, aby zobaczyć, że moduł został pominięty dla tego samego powodu lub jest to ze względu na brakujący symbol/p

+0

Pominięto również (była to moja pierwsza próba po pomijaniu pokrycia kodu). Brakuje również osłonek jetbrains i innych narzędzi. Teraz idę głębiej w temacie, mam nadzieję, że z wynikami w przyszłym tygodniu, więc wyślę tutaj. Proszę ocenić moje pytanie, czy uważasz, że jest użyteczne czy nie. – cseppento

0

w projekcie, dodać nowy plik xml i nazwę to dynamic.runsettings.

To powinno zawierać następujące informacje:

<?xml version="1.0" encoding="utf-8" ?> 
<RunSettings> 
    <DataCollectionRunSettings> 
    <DataCollectors> 
     <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> 
     <Configuration> 
      <CodeCoverage> 
      <ModulePaths> 
<!-- 
About include/exclude lists: 
Empty "Include" clauses imply all; empty "Exclude" clauses imply none. 
Each element in the list is a regular expression (ECMAScript syntax). 
An item must first match at least one entry in the include list to be included. 
Included items must then not match any entries in the exclude list to remain included. 
It is considered an error to exclude all items from instrumentation as no data would be collected. 
--> 
       <Include> 
       <!-- <ModulePath>.*\\UnitTestProject1\.dll</ModulePath> --> 
       </Include> 
       <Exclude> 
       <ModulePath>.*CPPUnitTestFramework.*</ModulePath> 
       </Exclude> 
      </ModulePaths> 
      <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation> 
      <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses> 
      <CollectFromChildProcesses>True</CollectFromChildProcesses> 
      <CollectAspDotNet>False</CollectAspDotNet> 
<!-- 
Additional paths to search for symbol files. Symbols must be found for modules to be instrumented. 
If symbols are alongside the binaries, they are automatically picked up. Otherwise specify the here. 
Note that searching for symbols increases code coverage runtime. So keep this small and local. 
<SymbolSearchPaths> 
    <Path>C:\Users\User\Documents\Visual Studio 11\Projects\ProjectX\bin\Debug</Path> 
    <Path>\\mybuildshare\builds\ProjectX</Path> 
</SymbolSearchPaths> 
--> 
      <Functions> 
       <Exclude> 
       <Function>^std::.*</Function> 
       <Function>^ATL::.*</Function> 
       <Function>.*::__GetTestMethodInfo.*</Function> 
       <Function>^Microsoft::VisualStudio::CppCodeCoverageFramework::.*</Function> 
       <Function>^Microsoft::VisualStudio::CppUnitTestFramework::.*</Function> 
       <Function>.*::YOU_CAN_ONLY_DESIGNATE_ONE_.*</Function> 
       </Exclude> 
      </Functions> 
      <Attributes> 
       <Exclude> 
       <Attribute>^System.Diagnostics.DebuggerHiddenAttribute$</Attribute> 
       <Attribute>^System.Diagnostics.DebuggerNonUserCodeAttribute$</Attribute> 
       <Attribute>^System.Runtime.CompilerServices.CompilerGeneratedAttribute$</Attribute> 
       <Attribute>^System.CodeDom.Compiler.GeneratedCodeAttribute$</Attribute> 
       <Attribute>^System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute$</Attribute> 
       </Exclude> 
      </Attributes> 
      <Sources> 
       <Exclude> 
       <Source>.*\\atlmfc\\.*</Source> 
       <Source>.*\\vctools\\.*</Source> 
       <Source>.*\\public\\sdk\\.*</Source> 
       <Source>.*\\microsoft sdks\\.*</Source> 
       <Source>.*\\vc\\include\\.*</Source> 
       </Exclude> 
      </Sources> 
      <CompanyNames> 
       <Exclude> 
       <CompanyName>.*microsoft.*</CompanyName> 
       </Exclude> 
      </CompanyNames> 
      <PublicKeyTokens> 
       <Exclude> 
       <PublicKeyToken>^B77A5C561934E089$</PublicKeyToken> 
       <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken> 
       <PublicKeyToken>^31BF3856AD364E35$</PublicKeyToken> 
       <PublicKeyToken>^89845DCD8080CC91$</PublicKeyToken> 
       <PublicKeyToken>^71E9BCE111E9429C$</PublicKeyToken> 
       <PublicKeyToken>^8F50407C4E9E73B6$</PublicKeyToken> 
       <PublicKeyToken>^E361AF139669C375$</PublicKeyToken> 
       </Exclude> 
      </PublicKeyTokens> 
      </CodeCoverage> 
     </Configuration> 
     </DataCollector> 
    </DataCollectors> 
    </DataCollectionRunSettings> 
</RunSettings> 

Zapisz tego. To, co jest wyjątkowe w tym pliku, to sekcja CodeCoverage \ ModulePaths \ Include ma wykreślone dziecko podrzędne ModulePath. Będzie to teraz obejmować wszystkie biblioteki DLL, które znajdzie w zasięgu kodu.

Teraz Kliknij na Test -> Ustawienia testu -> Wybierz plik ustawień testu i określ plik dynamic.runsettings. Twój zasięg kodu będzie teraz korzystać z tego niestandardowego pliku ustawień.

Kliknij opcję Analiza zasięgu kodu i uruchom dowolne testy. Powinieneś zobaczyć swoją DynamicCode.dll pokazać się w wynikach pokrycia (Mam zasłonięte moją nazwę stacji roboczej poniżej):

enter image description here

Zauważ, że dodaliśmy nową metodę do pliku .cs.txt nazywa BONK i (poprawnie) pokazuje się jako 100% niepokryty.