The build of PerfView depends on two packages of support files.
- Microsoft.Diagnostics.Tracing.TraceEvent.SupportFiles.1.0.0
- PerfView.SupportFiles.1.0.0
These two Nuget packages contain binaries (DLLs and tools) that are assumed as part of the underlying platform, so are not created as part of the build. These include
- The native code msdia* library that allows you to decode PDB files
- The native KernelTraceControl* library that allows for merging of ETL files
- Managed COM interop assemblies (generated with the TLBEXP tool on native type libraries)
These Nuget packages are available on https://www.nuget.org/ so the build should 'just work' but it is certainly possible that at some point we will want to update these binaries. and this document indicats how to do this.
There are files in the 'NugetSupportFiles' directory for regenerating these two Nuget packages. We go through the procedure for PerfView.SupportFiles.1.0.0 but the same technique works for Microsoft.Diagnostics.Tracing.TraceEvent.SupportFiles.1.0.0.
It is likely that you only need to update a subset of all the DLLs in the package. Thus you need to start with an existing set. You can do this by running editing and running the PerfView.SupportFiles.Populate.bat script.
- First look in packages directory to see what the latest version is and modify the PerfView.SupportFiles.Populate.bat copy from that. If you don't update this file to take from the currnet version, you will end up making a package with old binaries in it, which is undoubtely not what you want.
- Then you can run the batch file. This copies that files you are currently using to form a baseline for the new package in a subdirectory of the src\NugetSupportFiles directory.
This batch script also has a list of the files it is going to copy so that even if you don't have the existing nuget package, you can populate the new package 'by hand' from 'raw' files.
This is dependent on exactly what you want to do. However something you should ALWAYS do is to update the version number in the PerfView.SupportFiles.nuspec file You should also update the releaseNotes element in the nuspec file. Thus at this point you have updates the .Populate.bat file and the *.nuspec file.
There is a script called PerfView.SupportFiles.MakeNuget.bat which does this. It is a one line script, and generates a new *.nupkg in the current directory.
The PerfView reposititory has a Nuget.config file that tells nuget to look in the src\NugetSupportFiles
directory for nuget packages. The 'Directory.Build.props' file is the file that tells
what paritcular version of each of the .SupportFiles packages it should actually use.
THus at this point (even before uploading to Nuget.org) you can update the Directory.Build.props to
point at your latest version, and build PerfView and test that the new behavior works.
Note that you can't actually check in this change to Directory.Build.props, however because anyone else trying to build PerfView (include the PerfView appveyor system) does not have access to your new nuget packages. This this change is only for local testing (at the moment)
Nuget now requires that all Microsoft owned packages use nuget's package signing in order to be uploaded. You also need special permission to upload them. See Internal Docs for more on this.
It does take a few minutes after uploading for the packages to become visible. Be patient.
Once the new packages are available you can actually check in the changes to Directory.Build.props to use the new packages officially. It is a good practice to update the *.Populate.bat file and *.nuspec files to the NEXT version (that way you can only make a mistake if you forget to do this TWICE).