Indirect reference issues

Question

Indirect reference issues

peters opened this issue 11 years ago · 19 comments

peters commented 11 years ago

Answer 1 · 2013-09-25T14:58:37.000Z

Prior art: #73

Answer 2 · 2013-09-25T15:02:05.000Z

Also, can you share your packages.config for that project?

Answer 3 · 2013-09-26T07:28:46.000Z

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="HigLabo" version="2.3.4.0" targetFramework="net45" />
  <package id="Magick.NET-Q16-x86" version="6.8.6.801" targetFramework="net45" />
  <package id="MarkdownSharp" version="1.13.0.0" targetFramework="net45" />
  <package id="Microsoft.Bcl" version="1.1.3" targetFramework="net45" />
  <package id="Microsoft.Bcl.Async" version="1.0.16" targetFramework="net45" />
  <package id="Microsoft.Bcl.Build" version="1.0.10" targetFramework="net45" />
  <package id="Microsoft.Web.Xdt" version="1.0.0" targetFramework="net45" />
  <package id="ModernUI" version="1.1.0.1" targetFramework="net45" />
  <package id="NLog" version="2.0.1.2" targetFramework="net45" />
  <package id="NuGet.Core" version="2.7.0" targetFramework="net45" />
  <package id="Rx-Core" version="2.1.30214.0" targetFramework="net45" />
  <package id="Rx-Interfaces" version="2.1.30214.0" targetFramework="net45" />
  <package id="Rx-Linq" version="2.1.30214.0" targetFramework="net45" />
  <package id="Rx-Main" version="2.1.30214.0" targetFramework="net45" />
  <package id="Rx-PlatformServices" version="2.1.30214.0" targetFramework="net45" />
  <package id="semver" version="1.0.5" targetFramework="net45" />
  <package id="ServiceStack.Text" version="3.9.63" targetFramework="net45" />
  <package id="Shimmer" version="0.7.0" targetFramework="net45" />
  <package id="Shimmer.Client" version="0.7.0" targetFramework="net45" />
  <package id="Shimmer.Core" version="0.7.0" targetFramework="net45" />
  <package id="System.IO.Abstractions" version="1.4.0.66" targetFramework="net45" />
</packages>

Answer 4 · 2013-09-26T07:42:49.000Z

I thought it was related to the Microsoft.Bcl update but you've got the latest version.

I wasn't able to recreate the scenario using a blank WPF application (.NET45) and those dependencies, but the MSBuild output itself (verbose plz) might help spot where this is hiding.

Answer 5 · 2013-09-26T07:49:50.000Z

@shiftkey You got mail! About 2,5 MB worth of logs!

C:\Users\peters\Documents\GitHub2\opus>msbuild opus.sln /p:Configuration=Release
 /verbosity:diag /t:Clean,Rebuild > build_output.txt

Answer 6 · 2013-09-27T06:58:12.000Z

@shiftkey Resolved in 0.7.1

BUT! I'm now unable to create a new release...

PM> New-Release
Shimmer: Clearing existing nupkg files from folder bin\x86\Release\
Shimmer: Building project opus
Shimmer: Publishing release for project opus
Shimmer: Checking C:\Users\peters\Documents\GitHub2\opus\src\opus\bin\x86\Release\ for packages

Shimmer: No .nupkg files were found in the build directory
Shimmer: Have you built the solution lately?

👊

Answer 7 · 2013-09-27T07:10:05.000Z

@peters I think you're hitting what I saw here #167 - and I think this is related to the "Building project" step

I've chosen to just Build here (not Rebuild, no Clean) - but I remove any nupkg files before that.

I'm not quite happy with this, as I've been bitten a couple of times where a change I make won't trigger a build (and thus a new package).

I can open a change here to make it clean and build, or rebuild (if the API supports it) to ensure we're always doing a build here.

Seem legit?

Answer 8 · 2013-09-27T07:15:01.000Z

I've chosen to just Build here (not Rebuild, no Clean) - but I remove any nupkg files before that.

I've tried:

Clean, Build -> New Release
Clean, Rebuild -> New Release
Clean -> New Release

None of them work and results in #177 (comment)

I can open a change here to make it clean and build, or rebuild (if the API supports it) to ensure we're always doing a build here.

Clean, Rebuild would be ideal.

Answer 9 · 2013-09-27T07:16:34.000Z

@peters this is on Windows 7, right?

Answer 10 · 2013-09-27T07:20:42.000Z

@shiftkey

Same issue in VS 2012 Ultimate also

Answer 11 · 2013-09-27T07:26:28.000Z

Awesome, I think there's something messy with how Powershell v2 and the EnvDTE automation behave.

On my Windows 8 machine that operation blocks, but I suspect it's not blocking on your side (which fits with the "always no packages" step.

Answer 12 · 2013-09-27T07:28:53.000Z

On my Windows 8 machine that operation blocks,

Aha, it's all swooosh here. Just waiting for that Windows 8.1 crap to be released so i can upgrade 👯

Answer 13 · 2013-09-27T07:36:26.000Z

#59 should involve Windows XP SP3, Windows Vista, Windows 7 and Windows 8! Fire up ze VM'S :D

Answer 14 · 2013-09-27T07:37:07.000Z

Maybe vista can be skipped, (hopefully) nobody uses that crap anyway

Answer 15 · 2013-09-27T07:51:14.000Z

Right.

I can make the "delete existing .nupkg files and build" run based on the version of Powershell you're running - to unblock your testing. It'll still fail if you haven't got packages, but it stops us being too cute with automating this stuff.

Answer 16 · 2013-09-27T14:41:31.000Z

@shiftkey Hmm, the indirect reference issue is suddenly reappeared.. wtf is going on :/

Answer 17 · 2013-09-27T23:50:17.000Z

@peters I couldn't spot anything strange in the build log that might point to a mismatch in assemblies.

I'll keep an eye out in my testing but I can't guarantee an ETA at this stage.

Answer 18 · 2013-10-26T09:43:16.000Z

@shiftkey Checkout this tool and it should reveal any inconsistencies. I used it the other day and it worked great. Visual Studio 2013 also has the ability to generate assembly bindings on-the-fly. See http://msdn.microsoft.com/en-us/library/2fc472t2.aspx

Answer 19 · 2014-03-28T07:54:33.000Z

The problem seem to have disappeared in nuget 2.8. I'll reopen if it comes back to haunt us :/