Have library in .NET 4.5 that uses a third party library that has an assembly name as XXX.v15.4.dll. The project builds properly, but when trying to run the project it looks for "XXX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k.dll"
Note that it works in RC2 without a problem.
It should look for "XXX.v15.4.dll"
An error message comes up with the following:
Failed to make the following project runnable: PROJECT(.NETFramework,Version=v4.6.1) reason: Could not find file 'C:\Projects\MainBranch\BlahBlah\bin\Debug\XX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k.dll'.
dotnet --info output:
.NET Command Line Tools (1.0.0-preview2-003121)
Product Information:
Version: 1.0.0-preview2-003121
Commit SHA-1 hash: 1e9d529bc5
Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
It looks as if there is a badly generated path path which uses the full assembly identity in place of the assembly Name. Consider the message:
C:\Projects\MainBranch\BlahBlah\bin\Debug\XX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k.dll
which is:
C:\Projects\MainBranch\BlahBlah\bin\Debug\{assemblyIdentity}.dll
where
assemblyIdentity = XX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k
Do you have a repro you can share? there are a lot of open questions here:
I expect we have something funny going on in this project which is not generating useful diagnostics.
Here are some steps which will reproduce an error message of this form, although possibly for a different reason.
I'm seeing Failed to make the following project runnable: WebApplication1 (.NETFramework,Version=v4.6.1) reason: Could not find file 'C:\dev\valhalla\xStPancrasSpike\WebApplication1\Library1\bin\Debug\fsharp.core, version=4.4.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.dll'. WebApplication1 C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets which is obviously a different library name from the one @DOMZE reported, but it seems to be an error of the same form - something has taken a fully-qualified assembly name and has then slapped .dll on the end, and then attempted to use that as a filename.
Note that the library in question is the F# core library (specifically v4.4.0.0), which gets added to an F# library project's references automatically by the build system. The C# library that references the F# library does not have an explicit reference to that same library, but it copies FSharp.core.dll into its bin\Debug folder. And evidently WebApplication1 is somehow picking up that reference, but is misinterpreting it.
(I came across this while attempting to consume an ordinary F# class library from an ASP.NET Core web application (running on .NET Framework 4.6.1 - I want the new ASP.NET Core API, but I need the full framework for various reasons, not the .NET Core runtime). You cannot reference F# class libraries (whether they are plain .NET libraries like this, or PCLs) directly from an ASP.NET Core web app, so I tried referencing it indirectly via a C# library. But I ran into this problem. As far as I can tell it is not possible to consume an F# class library through the project system. The only way to do it appears to be a project reference to a C# library that has a _file_ reference to the F# library, which is pretty horrible.)
@eerhardt is spending time in the "make runnable" code recently. Can you take a quick look?
I don't have F# tools installed on my machine, so it won't be a "quick look".
So I took a "medium look" at this. I was able to repro it on my machine.
The bug is coming from this file: project.fragment.lock.json. The CLI is reading that file, and using the file names from it. On my machine that file contains:
"runtime": {
"bin/Debug/Library1.dll": {},
"bin/Debug/fsharp.core, version=4.4.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.dll": {}
},
Which is the error we are seeing above - we are trying to copy that file that was specified in here, and that file doesn't exist.
I'm not sure who writes this file. I think it is VS. @BillHiebert @cdmihai - do you know who is writing project.fragment.lock.json?
@cdmihai @abpiskunov @eerhardt any progress on this? @piotrpMSFT
Been a while and blocking us to move to RTM
Any further progress on this? It looks like this may be the same thing that is blocking our project because we are referencing a regular C# library in order to utilize web references...
@DOMZE I tried a simple experiment in preview3 atop MSBuild and wasn't able to trigger this issue. Do you have a repro I can migrate?
I solved this issue by doing to things;
Maybe this can provide a hint to the deeper issue?
Im facing the issue referencing a project wich use Microsoft.WindowsAzure.ServiceRuntime version 2.5,
The referenced project uses an assembly in the following path:
C:\Program Files\Microsoft SDKs\Azure.NET SDK\v2.9\ref\Microsoft.WindowsAzure.ServiceRuntime.dll
But when i try to compile my netcore project in vs2015 it use the nex pat
C:****\ Program Files\Microsoft SDKs\Azure.NET SDK\v2.9\ref\Microsoft.WindowsAzure.ServiceRuntime.dll
Where the ** are the path to the project in my file system
The project.fragment.lock.json list the incorrect paht as ........\Program Files\Microsoft SDKs\Azure.NET SDK\v2.9\ref\Microsoft.WindowsAzure.ServiceRuntime.dll
That path does not exist, then i get the error message menctioned above
Most helpful comment
I solved this issue by doing to things;
Maybe this can provide a hint to the deeper issue?