How can I stop asp.net from blocking access to fil

Question

I repeatedly get build errors along the lines of the following:

Failed to make the following project runnable: <project name>(.NETFramework,Version=v4.6.1) reason: Access to the path 'C:\<path from root>\src\<project name>\bin\Debug\net641\win7-64x\<some dll, exe, config, whatever>' is denied.

I was getting similar errors from other folders but taking them out of source control helped (see below)

Sometimes manually going to the folder in Explorer > right click > properties > uncheck "read only" works for a successful build but then either VS or TFS locks the file again and the same build error returns

In particular at the moment there are two .dll files being added to the bin which are repeatedly set to "read only" and I have to manually fix that in file explorer upon rebuild. AFAIK these are not in source control, but the files in another project within the solution by the same name are checked in and not changing.

It may have something to do with the fact I'm using asp.net Core RC2 which is not official yet, plus I'm pairing it with Angular 2 RC1 but I don't think that's related.

One theory is that it has something to do with TFS since the errors don't seem to start until I put the project under source control.

I've seen a number of similar questions on Stack Overflow but no answers that even begin to resolve my own repetitive problem.

HINT: I was getting the same with transpiled .ts > .js files and taking them out of source control seems to have helped but I don't see the bin folder in source control at all (of course it's hidden in the solution explorer and I see no option to unhide in source control explorer, so not sure if it's there at all...)

Answer 1

I ended up removing app.config, and moving it's contents to project.json.

App.config contents (one that I removed):

<configuration>
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

Added this to project.json:

"runtimeOptions": {
  "configProperties": {
    "System.GC.Server": true
  }
},

I also installed latest dotnet/cli from github which has the fix for package folder DLLs with same issue. I used .NET Core SDK Installer and dotnet --version now shows 1.0.0-preview3-003585.

Remember to, remove \bin folder manually after you make changes and before you run next build. Clean task does not remove all the files.

Answer 2

I've added in the script section a postcompile:

"postcompile": [
  "cmd /c echo Removing read-only attributes in %project:Directory%\\bin\\ && cmd /c attrib -r  %project:Directory%\\bin\\* /s",
  "cmd /c echo Removing read-only attributes in %project:Directory%\\..\\packages\\ && cmd /c attrib -r  %project:Directory%\\..\\packages\\* /s"
]

works well for me

Answer 3

I found a work-around for this issue when it is file <project name>.exe.config causing the problem. Since that file is basically a copy of app.config I tried checking out app.config and the problem went away.

I was dead in the water because I couldn't compile the project. I hope this helps someone that is in the same predicament.

Answer 4

It seems this issue is under tracking, you can monitor it at link:

https://github.com/dotnet/cli/issues/3419

Answer 5

The problem appears to be TFS integration with .net Core, or something with TFS anyway.

The solution is generally to subvert TFS, which is unwieldy and should not be necessary. Here are a few things I've done...

• Using a .tfignore (similar to .gitignore) to prevent certain files (such as transpiled .ts => .js) from being checked in. This does not work without taking weird steps like installing this...
• Simply checking out and locking up any files still giving me trouble (see my answer to my other question here)
• Just about any other tactic to prevent TFS from checking in files that it shouldn't (sometimes as bad as just leaving them in the "Excluded Changes" list until someone else needs access, at which point I have to delete them all and/or undo all the changes)

All in all, I really hope Microsoft gets most or all the terrible bugs I've encountered worked out by the time .net Core is released officially. At this point I'm sorely tempted to become a node.js developer.