cc: @KrzysztofCwalina, @ahsonkhan
cc: @weshaggard, @ericstj
Any ETA on this? This is blocking my PR.
What's blocking you here?
If I understand correctly @stephentoub is just suggesting that we ship System.Memory as part of the 2.1 release. That seems reasonable if folks agree with it, and a requirement if we take a dependency on it as we are already doing. In that case it'll transition to stable along with the rest of the repo, when 2.1 ships.
Sorry, I don't think it's this issue specifically that's blocking me. 2.1 builds fine.
However, netfx does not. I get the following error:
C:\github\geoffkizer\corefx\pkg\frameworkPackage.targets(124,5): error : Assembly 'System.Net.Http' is missin
g dependency 'System.Memory' [C:\github\geoffkizer\corefx\pkg\NETStandard.Library.NETFramework\NETStandard.Li
brary.NETFramework.pkgproj]
Do you know what I need to do to fix this?
That's because we're still building a desktop implementation of System.Net.Http and its being included in https://github.com/dotnet/corefx/blob/master/pkg/NETStandard.Library.NETFramework/NETStandard.Library.NETFramework.pkgproj. Your change modified the desktop implementation to take a dependency on System.Memory which is not part of netstandard nor desktop itself. Issue https://github.com/dotnet/corefx/issues/23165 is tracking disabling that package completely. After 2.0 we don't plan to build any of the desktop implementations for the API that makes up NETStandard: that needs to live in the desktop.
The quickest fix for you to suppress the dangling dependency by adding the following to NETStandard.Library.NETFramework.pkgproj:
<ItemGroup>
<IgnoredReference Include="System.Memory" />
</ItemGroup>
The right fix is to disable all these desktop builds as I mentioned above, but you don't need to block yourself on that.
Thanks, that did the trick.
Sorry for jumping in from the right here.
A quick question. I just installed corefx v2.1.0-preview2-25616-02 in order to be able to have the imagesharp project (https://github.com/SixLabors/ImageSharp) dependency --> system.memory available. However, when using imagesharp to load a picture, via PS /gitRepos/CoreFx/corefx> Add-Type -Path /gitRepos/pictureManagement/Artifacts/imagesharp/SixLabors.Core.dll PS /gitRepos/CoreFx/corefx> Add-Type -Path /gitRepos/pictureManagement/Artifacts/imagesharp/ImageSharp.dll PS /gitRepos/CoreFx/corefx> $imageLoaded = [ImageSharp.Image]::Load('/Users/lars/Downloads/photo_2017-07-10_20-53-27.jpg') I get the following error:
The following exception occurred while retrieving member "Load": "Could not load file or assembly 'System.Memory, Version=4.0.0.0, Cultu
re=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified
1) How do I verify if system.memory is available in the powershell session context. I did [appdomain]::currentdomain.getassemblies() | Sort-Object -property fullname | format-table fullname and I cannot see system.memory mentioned there.
2) Is it because it is not part of the latest build at all yet?
3) Or do I actually need to change the version of system.memory required by imagesharp and built that project again?
I hope I'm making myself clear in the above, if not feel free to inquire and I'll reply back as soon as possible.
Thank you very much.
@ahsonkhan, would you know why the dll does not load for @larssb?
That question is more specific to how Powershell locates its assemblies, but I'd expect that they'd probe next to the assembly which is loading it, not necessarily every directory in the path. Also note that the version in master will be different so whatever is loading the assembly would need to handle the redirect.
@ericstj thank you for sending me in the right direction. I put the System.Memory.dll in the same folder as the ImageSharp required dll's and that was then loaded. However, now I'm getting an error telling me about the next required dll which is missing. But hey, now I just find that and put it in the same folder and put that on repeat until I'm there.
Thank you....
Sure, wish I had a pointer to Powershell's load semantics. @daxian-dbw might.
@joperezr is there anything special the System.Memory feature crew needs to do here with the nuspec or build files as part of shipping 2.1 or will marking the package stable be taken care of automatically for all packages in the release branch as part of shipping the eventual 2.1 RTW?
If there's nothing extra or specific to System.Memory, then any concerns with closing this out now?
Thanks
Nothing special is needed. As we prepare for shipping 2.1, we will mark all shipping packages as stable in one PR, which will include System.Memory, so no additional work from the feature crew is required. I'm fine with closing this issue now.
Thanks @joperezr for confirming.