Tablet resources smoke test

[mtarcha]

• Test tablet will be able to host services (Nuget, CI, Symbol Server)

DOD

• wiki page

[iivchenko]

TODO

• [x] Find micro SD
• [x] Check for viruses with DR.WEB
• [x] Create users
  • [x] For Slava
  • [x] For Me
  • [x] For Server Admin
• [x] Configure
  • [x] RDP
  • [x] Firewall for RDP
• [x] Minimize resource consumption
  • [x] Stop unnecessary services and apps
  • [x] Uninstall unnecessary apps, updates, roles etc.
• [x] Install serves
  • [x] Jenkins
  • [x] Nuget
  • [x] Symbol
  • [x] Source
• [ ] Defrag

[iivchenko]

Links to investigate

• Article about creating Nuget server with own feeds
• TeamCity as a Symbol Server and Source Server
• Symbol server over IIS and file share as good as for Nuget packages server I think!
• IIS and symstore
• Source Server and Symbol Server Support in TFS 2010
• An interesting source indexing project
• Code Project about Symbol server
• Symbol server setup
• Hosting your own Source & Symbol Server
• SymStore
• Symbol server GitHub
• Indexing tools
  • PDBGIT
  • GitTools
• NetFoundation and there is a symstore repo
• Deploy Site to IIS

[iivchenko]

. A native C++ PDB file contains quite a bit of information:

Public, private, and static function addresses Global variable names and addresses Parameter and local variable names and offsets where to find them on the stack Type data consisting of class, structure, and data definitions Frame Pointer Omission (FPO) data, which is the key to native stack walking on x86 Source file names and their lines A .NET PDB only contains two pieces of information, the source file names and their lines and the local variable names. All the other information is already in the .NET metadata so there is no need to duplicate the same information in a PDB file.

When you load a module into the process address space, the debugger uses two pieces of information to find the matching PDB file. The first is obviously the name of the file. If you load ZZZ.DLL, the debugger looks for ZZZ.PDB. The extremely important part is how the debugger knows this is the exact matching PDB file for this binary. That’s done through a GUID that’s embedded in both the PDB file and the binary. If the GUID does not match, you certainly won’t debug the module at the source code level.

The .NET compiler, and for native the linker, puts this GUID into the binary and PDB. Since the act of compiling creates this GUID, stop and think about this for a moment. If you have yesterday’s build and did not save the PDB file will you ever be able to debug the binary again? No! This is why it is so critical to save your PDB files for every build. Because I know you’re thinking it, I’ll go ahead and answer the question already forming in your mind: no, there’s no way to change the GUID.

[iivchenko]

.\nuget pack .\TestPackage.csproj -properties Configuration=Release -OutputDirectory .\bin .\nuget.exe push .\bin\TestPackage.1.0.0.nupkg -Source http://azjol-nerub:81/api/v2/package

& "C:\Program Files\Windows Kits\10\Debuggers\x86\symstore.exe" add /f .\TestPackage.pdb /s D:\SymStore\ /t "TestPackage" /v 1.0.0.0

pdbgit .\TestPackage.pdb -u https://raw.githubusercontent.com/CrazyCouple/Prototypes

[iivchenko]

Brief workflow

• Build binaries
• Create and push package
• pdbgit for pdbs
• push to symstore
• configure VS and resharper