[wix-devs] problem with floating version number in Core

[Rob Mensching]

This would not be an issue if we used specific versions. Until we do that (assuming we do), there is no project change to trigger out dated .nupkg dependencies.

The current design is why after a git pull, I tend to clean the repo before building.



From: Sean Hall <r.sean.hall at gmail.com>
Sent: Thursday, January 3, 2019 7:30 PM
To: Rob Mensching <rob at firegiant.com>
Subject: Re: [wix-devs] problem with floating version number in Core

No, but I can add that to my workflow if that's what needs to happen.

On Thu, Jan 3, 2019 at 8:25 PM Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com>> wrote:
Did you clean first? I've seen this happen if you have a project.assets.json left over from previous builds.

If you pull an upstream repo, you'll want to clean that repo and all downstream repos. The Home\cleanall.cmd is helpful in this case.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, January 2, 2019 7:30 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
Cc: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>
Subject: [wix-devs] problem with floating version number in Core

I pulled the latest code tonight and then ran appveyor.cmd for each repo.
It failed in Core, because the implicit 'dotnet restore' didn't pull the latest Data Nuget package. Which appears to be because dotnet/nuget didn't see any changes to the project file so didn't bother trying to see if there was a newer version. When I ran 'dotnet restore --force' it did pull the latest.

Do you think this is worth addressing?
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/