BuildTools should be able to run against any CLI version

[jonmill]

Right now, build tools is compiled against a specific version of the Shared Framework; it would be nice if it supported running against any version of the SFX that was already on the target machine. This would significantly help the CLI scenario since the CLI repo already has a SFX on-box; however, the SFX version is usually much higher than the build tools version

[mellinoe]

What work does fixing this involve? Does the problem come from the version hard-coded here?

[joperezr]

@mellinoe that is part of the problem because that is the minimum version we look to have in the runtime, but another part of it is that we also need to compile against one version of the framework, which is where the real problem is. Basically, there is no easy way to ensure that the version we compile against in buildtools side, will match/support the version that the consumer of buildtools will have at runtime. I'm not sure there is an easy way to fix this.

[mellinoe]

Is that part actually a problem as long as the version CLI uses is newer, though? It's not like we're breaking interface or behavior compat between earlier and later framework assemblies.

[jonmill]

@weshaggard might have some ideas here

[weshaggard]

I think there are a couple possible paths.

1. Generate a runtime.config file with the right version as part of init-tools.cmd
2. By-pass the root dotnet.exe and instead use the dotnet.exe direction from the shared framework.

[eerhardt]

Any update on this? This issue lowers the ability to adopt buildtools in new repos. Currently in core-setup and cli repos, we are downloading 2 versions of the CLI. And now that we are trying to set up the dotnet/sdk repo, we will have to do the same if we want to use buildtools.

For starters, can we just move buildtools up to run on the RTM version of the shared framework? At least then these repos can stop downloading 2 versions of the CLI just to build...

[weshaggard]

@crummel can you please have a look at this with your other BuildTools investigations?

cc @markwilkie

[mellinoe]

I was chatting with @joperezr the other day and I didn't understand some stuff that came up regarding this:

• Why don't 1.0.0-prerelease versions "roll-forward" to 1.0.0 stable? I realize there may be incompatible changes made between versions, but the same is also true for different pre-release versions, and it's my understanding that this works, as long as the installed version is higher.
• It seems like any higher version should be applicable to me. We're heavily restricted in the kinds of backwards-compatible changes we are allowed to make in our libraries, so can't we pretty much always guarantee this is a safe thing to do? At the very least, there should be an option to allow it.

[eerhardt]

Why don't 1.0.0-prerelease versions "roll-forward" to 1.0.0 stable?

I know this was a conscious decision made by the DotNetHost. Only pre-release versions are allowed in the roll-forward behavior. @schellap and @gkhanna79 would have the full reasoning behind this policy. @piotrpMSFT might as well.

[schellap]

Stable versions ex: 1.0.0 will be automatically rolled forward to servicing patch updates 1.0.n. A pre-release 1.0.0-pre will not roll forward to patch updates as that is not the intention. It is to make this distinction. Pre-release we try to pick as compatible version as we can in pre-release bands to not break hosting providers with multiple apps.

[mellinoe]

Hm, maybe there's some more context that I'm missing, but it seems too restrictive to me... It might become a big headache going forward, especially for folks trying to maintain portable applications across framework versions. At the very least, it should be possible for us to say that an app supports more than one framework version, or a range, etc. Is anything like that possible? With that feature, we could just say that the buildtools apps all support several versions that we've tested.

[markwilkie]

@crummel who also cares about stuff like this right now.

[crummel]

I'm looking at this now.

[crummel]

Addressed by #1107 and #1125, closing.

[weshaggard]

Thanks @crummel what is your plan for rolling this out the the other repos?

[crummel]

@weshaggard I'm going to take a look and see if there's a workaround for the upgrade concerns that @livarcocc has - i.e. once support is dropped in CLI for project.json what happens. I'm also planning to look into whether it's feasible to get buildtools off project.json now - do you know who was looking at it before?
I also tried "latest" in .cliversion, which CLI wants, and got some errors, I haven't looked into that in depth yet.

[weshaggard]

I don't think anyone was looking at removing project.json from BuildTools repo. We cannot even consider that until we have new tools in places that can be used.

Please make sure there are tracking issues for everything left. I would like to get the bootstrapping changes into corefx before we go down the route of removing project.json files and the like because I do believe there is value independently of centralizing the logic.