Sdk: Asp.Net Core RC2 Error "Failed to make the following project runnable"

[skushubar]

Steps to reproduce

I have a MVC project I have just upgraded to RC2 and is checked into version control. When I build the project with "dotnet build" I get an access denied error on the config file. If I checkout app.config (e.g. remove the read only flag) it will build successfully.

Expected behavior

Project should build.

Actual behavior

I get the error:

Failed to make the following project runnable: xxx (.NETFramework,Version=v4.6.1) reason: Access to the path 'E:...\bin\Debug\net461\win7-x64\xxx.exe.config' is denied.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde21225e

Runtime Environment:
OS Name: Windows
OS Version: 6.3.9600
OS Platform: Windows
RID: win81-x64

[TheRealPiotrP]

@skushubar I'm not clear on the fix here. Are you asking for dotnet to be aware of your version control system and to check out files on your behalf?

[gdiedoardo]

@piotrpMSFT I had the same issue but on a dll (EntityFramework.SqlServer.dll).
There is a way to tell dotnet to ignore the files' read only flag?
Thanks

[skushubar]

@piotrpMSFT No - I'd actually like to keep the file checked in - the checkout is just a workaround to get the build to succeed. The problem is that during the build, app.config is copied and renamed to xxx.exe.config. It appears that once the file is copied, the config file is modified by dotnet to add (in my case at least) an assemblyBinding section. Since the original file was copied with the read-only flag - the build fails trying to modify a file it has created. The fix would be for dotnet to remove the read-only flag from the config file that it created and wants to modify.

[tonyqq]

Do you need app.config? Check https://msdn.microsoft.com/en-us/library/ms733932%28v=vs.110%29.aspx

If you are using IIS to host your service, use a Web.config file. If you are using any other hosting environment, use an App.config file.

I had the same issue. I had file app.config in my project with the following content:
<configuration>
<runtime>
<gcServer enabled="true"/>
</runtime>
</configuration>

I deleted app.config file and it works now.

[shah-123]

Removing app.config fixed our issue to certain extent. We moved this app.config setting into project.json.

We are facing issue with EntityFramework.Sqlserver.dll. We have DbContext project which needs reference to EntityFramework and RepositoryProject which needs reference to EntityFramework and references DbContext project. This is when we get EntityFramework.SqlServer error mentioned above.

We have to manually remove "net461" folder under bin\Debug to compile the project every time.

Any fix?

[TheRealPiotrP]

The issue seems to be here. We are assuming that the config file is writeable. We need to investigate our general approach to read-only attributes for files copied to output. I'm not convinced that always removing the flag should be happening in CLI, but this case shows we can't simply "do nothing".

@eerhardt @livarcocc @brthor @sokket what are your thoughts on this?

Bumping out to RTM. There is an obvious workaround here, though it's not a pretty experience.

[eerhardt]

The fix would be for dotnet to remove the read-only flag from the config file that it created and wants to modify.

That has my vote. If we are copying a file to the output directory, and expecting to change it, we should make it writable.

[smbecker]

I am seeing this issue as well if I use globbing in dotnet build with --output specified. I do not have any app.config files.

command:
dotnet build **/src/**/project.json --configuration Debug --framework net451 --output <path>

[mafshin]

I have the same issue. If a project references another project, the build path is computed relative and can't find the binary file. Please provide a workaround.

Failed to make the following project runnable: XXXX (.NETFramework,Version=v4.6.1)

reason: Could not find a part of the path 'C:\Projects\YYYYYY\bin\Debug\log4net.dll'.   

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 

[Frisch12]

Fixed for DLL files in bin directory with: https://github.com/dotnet/cli/pull/3794

[dsaf]

How come this issue is still not fixed? I am using the stable release and also Microsoft's very own source control system - Team Foundation Server ®. Simply created a default new project against rock-solid .NET 4.5.2.

[johnkattenhorn]

We also have this issue when trying to build a dotnet core app referenced within a Service Fabric project. Only seems to be a problem when we build the .sfproj file via the command-line and MSBUILD, build via VS works fine.

[kevin-work]

I have the same error as @mafshin but with a different DLL. Any update on this? Perhaps we should make a separate issue for this? This error is different to the original OP's error and has already been fixed.

[olivier-spinelli]

Same here. The behavior is "funny".
After having compile correctly, suddenly the "Failed to make the following project runnable..." pops: it complained about a dll not found in C:\Dev\MyProject*src*\packages\MyLib.1.0.0\lib\net45\MyLib.dll".

What src is doing here? I changed the folder layout, getting rid of the src sub directory (all the projects are now rooted in the solution directory). And now, I get: "not found in C:\Dev\packages\MyLib.1.0.0\lib\net45\MyLib.dll"!
One directory above!

And he is "right" (joke of course): if I copy the whole /packages/ folder in the Dev directory: he finds it...
This, up to me is definitely a serious issue.

[ChaosEngine]

I got around it by converting *.xproj project (with project.json) to plain old *.csproj (with packages.config deps). Then used this project as a start for further dependency chain.

[olivier-spinelli]

Glad to see we are not alone on earth!
I'm afraid that you must be right.
xproj/csproj/nuget seems really buggy...

[MelbourneDeveloper]

I am getting this error message, but perhaps the cause of the problem is different for me. I have a project called Adapt.Data.Generic. My runnable project (ASP.NET Core - .NET Framework) is called Adapt.REST. Adapt.REST references Adapt.Data.Generic by putting the project in the project.json like this:

"Adapt.Data.Generic": {
"target": "project"
}

The problem is that the project.fragment.lock.json (which I have no control over), keeps looking for the DLL here:

"runtime": {
"../Adapt.Presentation.AES/Bin/Adapt.Data.Generic.dll": {},
"bin/Debug/Adapt.Model.Common.dll": {}
}

But, the folder "Adapt.Presentation.AES" does not even exist. I have searched through all the files in the solution and I CANNOT find any text which points to Adapt.Presentation.AES. I have no idea why it is looking for the DLL there.

Here is the compilation error I get:
Severity Code Description Project File Line Suppression State
Error Failed to make the following project runnable: Adapt.REST (.NETFramework,Version=v4.6) reason: Could not find a part of the path 'C:\AdaptSource\AES\Adapt.Presentation.AES\Bin\Adapt.Data.Generic.dll'. Adapt.REST C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets 262

[MelbourneDeveloper]

@ChaosEngine, how did you manage to extricate yourself from the xproj disaster?

Microsoft has been saying that they are going to ditch the xproj format for a long time, but nobody has explained to me how to make the move. I have a feeling that all these problems are tied to xproj. But, I can't find any documentation on how to get off xproj. Microsoft were promising that there would be a patch soon that would automatically convert xproj to csproj. I'm totally willing to do that work myself but I have no idea how.

Is there a tutorial or article on how to do this somewhere?

[ChaosEngine]

@MelbourneDeveloper I was having similar situation as you; two project with project.json's referencing each other. When updated to ASP.NET > 1.0.0-rc1 this error started to appear.

So I switched your counterparting Adapt.Data.Generic back from (.xproj and project.json) to plain old *.csproj (which in fact it previously was in t he beginning).
The just include the reference of Adapt.Data.Generic in project.json:
"Adapt.Data.Generic": { "target": "project" }
finally, I got rid of this "runnable*" error.

Your counterparting Adapt.REST still has project.json and *.xproj.

[yasenm]

In our team we started recently a project.

Did try the fix with removing the app.config and worked for a brief period before checking the change and did appear again after that. This is major issue for us as we use TFS for all our projects. Can't believe this is not something considered before.

Did all kind of research and nothing helped. This is simply discouraging.

[rpokrovskij]

@MelbourneDeveloper
I have one core sulution (web mvc) and many proj C# libraries.
In my case total removing nuget packages from all my proj projects (together with deleting all files in package folder) with next returning them back helped me. You would aslo need to remove all together runtime / assemblyBinding configuration sections from unit test configs.

What doesn't help: "Consolidate on sulution level". It just show that all assemblies are consolidate

[AllanTouring]

I followed the link provided in the fix by @Frisch12. There is a workaround to remove the read only attribute from offending file and directory in the project.json file. I modified this to remove read only from the whole bin directory as:

"scripts": { "precompile": [ "cmd /c echo Removing read-only attributes in %project:Directory%\\bin\\ as a workaround&& cmd /c attrib -r %project:Directory%\\bin\\* /s" ], "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] }

[richb8]

We're also getting these access denied issues when our project is checked into TFS. Everytime we want to build or publish the project, we have to checkout all the files, delete the bin and obj directories and rebuild.

[blackdwarf]

I've just checked this against the latest tooling based on MSBuild. I've added a read only flag to web.config and did dotnet build followed by dotnet run. The error does not repro anymore.

I will go ahead and close this issue as fixed in MSBuild. If you still repro it on the latest tooling, please reopen.