Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

This change make DacTableGen work for VS2017#17004

Merged
vancem merged 2 commits into
dotnet:masterfrom
vancem:DacTableGenFor2017
Mar 18, 2018
Merged

This change make DacTableGen work for VS2017#17004
vancem merged 2 commits into
dotnet:masterfrom
vancem:DacTableGenFor2017

Conversation

@vancem
Copy link
Copy Markdown

@vancem vancem commented Mar 17, 2018

There was a issue (see https://github.com/dotnet/coreclr/issues/11305) where a tool
used in the CoreCLR build called DacTableGen requires a old version of the
msdia120.dll. The symptom is that this tool would fail with a class not registered errror if
you build on a machine with only VS2017. This is blocking upgrading to VS2017.

This tool comes from a very old nuget package microsoft.dotnet.buildtools.coreclr, which
we no longer can build easly. Our guidance now is to move tools that are only used in
one repository (like this one) out of nuget packages and simply build them as part of the build.

This change makes a step in that direction. The DacTableGen code actually was already
in the CoreCLR repo, so this change

  1. Fixes the source of DacTableGen so that tool no longer needs a com object to be registered
    (but it DOES need msdia140.dll to be on the path. This is true for VS2017.
  2. Turns on the build of DacTableGen
  3. Change the build use the built DacTableGen (unless running on VS2017, in that case we use the
    the version in the tool package.
    4.) Remove the hack that warns people to register msdia120 (since you don't need to anymore)

There is also an unrelated addition to the docs.

This change should still work for VS2015 (because it falls back to the old DacTableGen in that case)

Finally we should move to using the Linux method of creating the DAC, and so all these tools and
their nuget package can be removed.

@mikem8361

There was a issue (see https://github.com/dotnet/coreclr/issues/11305) where
a tool used in the CoreCLR build called DacTableGen requires a old version of the
msdia120.dll.   The symptom is that this tool would fail with a class not registered errror.

This tool comes from a very old nuget package microsoft.dotnet.buildtools.coreclr, which
we no longer can build easly.    Our guidance now is to move tools that are only used in
one repository (like this one) out of nuget packages and simply build them as part of the build.

This change makes a step in that direction.  The DacTableGen code actually was already
in the CoreCLR repo, so this change

1. Fixes the source of DacTableGen so that tool no longer needs a com object to be registered
    (but it DOES need msdia140.dll to be on the path.  This is true for VS2017.
2.  Turns on the build of DacTableGen
3. Change the build use the built DacTableGen (unless running on VS2017, in that case we use the
    the version in the tool package.
4.) Remove the hack that warns people to register msdia120 (since you don't need to anymore)

There is also an unrelated addition to the docs.

This change should still work for VS2015 (because it falls back to the old DacTableGen in that case)

Finally we should move to using the Linux method of creating the DAC, and so all these tools and
their nuget package can be removed.
These builds have a version number that follows the the versioning scheme described below (month number/day of month),
but they also will have a component that indicate which Git Branch the are working from

* preview1 - are daily builds from the 'release/*' branch where * is the next official version to be released
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* should be escaped so that it does not cause the rest to be italic

but they also will have a component that indicate which Git Branch the are working from

* preview1 - are daily builds from the 'release/*' branch where * is the next official version to be released
* preview2 - are daily builds from the 'master' branch (where active work happens first (typically))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to be true like for next <2 weeks, and then these suffixes are going to change again.

@vancem vancem merged commit 4e1ec7f into dotnet:master Mar 18, 2018
clr_unknown_arch()
endif()

set(DACTABLEGEN_EXE ${CMAKE_CURRENT_BINARY_DIR}/../../../ToolBox/SOS/DacTableGen/dactablegen.exe)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nit - Instead of this deep relative path, the following should work: ${CMAKE_BINARY_DIR}/src/ToolBox/SOS/DacTableGen/dactablegen.exe

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not like the ugly relative path, I will give that a try.

@vancem
Copy link
Copy Markdown
Author

vancem commented Mar 19, 2018

cc: @jashook

vancem pushed a commit to vancem/coreclr that referenced this pull request Mar 19, 2018
vancem pushed a commit that referenced this pull request Mar 19, 2018
@vancem vancem deleted the DacTableGenFor2017 branch May 31, 2018 13:04
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants