5

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...)

Methodician
  • 2,396
  • 5
  • 30
  • 49
  • I think you already may have answered your own question, "One theory is that it has something to do with TFS". On it's face that is what is happening. Suggestion: check the folder's security setting every time you synch with TFS and also always run VS as an administrator – DaniDev Jun 20 '16 at 17:18
  • You shouldn't be checking the compiled binaries from the project bin folder in to source control. Once checked in files are set to read only until checked out. If you need/want to check the binaries into TFS, move them outside the project (post build step maybe) to a folder just for this. When you compile VS needs to be able to delete then rewrite all of the binaries for the project you are compiling. – Kevin Jun 20 '16 at 17:38
  • One way to test this... Check out the entire solution. If, while you have "everything" checked out, the problem disappears, then something that VS needs to rewrite during a compile is getting checked in. Then you can figure out what it is and remove it from source control. – Kevin Jun 20 '16 at 17:54
  • @DaniDev my problem is that I do not see those in the source control explorer. They are hidden in the solution explorer but I don't see an "unhide" option in the source control explorer so not sure if they're even checked in. I'm pretty new to TFS - is there a different way to go about it? – Methodician Jun 20 '16 at 18:08
  • Do you run VS as admin? – null canvas Jun 20 '16 at 18:56
  • First thing you want to try before anything is as I mentioned in my earlier comment is: when you start VS do right click => and then "Run as Administrator". If that does solve your problem then we should look into the FS permissions – DaniDev Jun 20 '16 at 19:10
  • Ah, yes I am running as admin. I have it set to always run as admin. – Methodician Jun 20 '16 at 19:47
  • Is it possible that files inside "hidden" folders are not displaying in source control explorer? Is there a way to show them if so, or a different way to get them out of source control than deleting them there? As far as I can tell, they are not in source control. I only mentioned that as a possible cause because I don't know for sure that they are not and cannot seem to verify... – Methodician Jun 20 '16 at 19:49
  • Did you get the error during TFS build or local build? Which version of TFS are you using? – Cece Dong - MSFT Jun 21 '16 at 09:02
  • While I'm unsure how to determine my TFS version, it's a new install so I'd guess the latest. How can I tell? I'm new to TFS too so not sure what a "TFS build" is, but I believe it's a standard "local build" as it's the same build I always do from within VS whether using TFS or not. Sorry for the imprecise response... – Methodician Jun 22 '16 at 19:27

5 Answers5

3

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.

Community
  • 1
  • 1
Methodician
  • 2,396
  • 5
  • 30
  • 49
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.

Clint B
  • 4,610
  • 2
  • 18
  • 22
3

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

DOMZE
  • 1,369
  • 10
  • 27
1

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

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

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • Thanks for pointing that out. I did come across it earlier when I had that exact same issue but I was able to remove that item from source control, which fixed things. I'm not sure what I'm currently experiencing is a variation on the same or something else but I do not see these items in source control (again, could they be "hidden"?) – Methodician Jun 22 '16 at 19:37
  • Source Control can hide deleted items, but won't hide other files. You may create a new workspace to perform get latest, then build the project to see what will you get. – Cece Dong - MSFT Jun 23 '16 at 09:42
0

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.

CrnaStena
  • 3,017
  • 5
  • 30
  • 48