Hmm. Strange. Can you send me a test case, and note which file(s) are read only? (Not sure if zip will preserve that). I’m out of office for a few hours, but I’ll recheck later.
Very simple to reproduce
New Oxygene Class Library
Add New Application Configuration File (App.config)
Open project folder in Explorer
Set App.config - Read Only
Build
Access Denied error
Severity Code Description Project File Line Suppression State
Error () Access to the path ‘C:\Users\afelton\source\repos\Test2\Bin\Debug\Test2.dll.config’ is denied. Test2 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets 53
Alex
By bad; my fix cleared the read-only flag at the very end, but it seems even just setting the modified date on a read-only file fails — and that was happening before I reset read-only.
That said, it’s odd that it only failed form you on a second rebuild; for me, the very first build failed on that.
Fixed now, and doing a new build for you.
Just to make things clear. The bit that let you compile once, was when you had a Copy Always file that was Read Only. The .config file always failed first time.
Alex
1 Like
A couple things failed last night that kept me from giving you a new build, but there’s one up now.
Merry Christmas! 
Hi Marc
Hope you had a pleasant break.
Have just tried build C and there is still a problem with ReadOnly Content/Copy Always files
To repro
New Oxygene .Net Class Library
Add a new .txt file to the project, set it to Copy Always in it’s properties,
then in Explorer make the file Read Only
Now build, which will work and you should see the .txt file in the dest directory and it will be Read Only
Rebuild or Clean will give Access Denied error on the .txt file
Alex
Tried to put in a temporary workaround by adding a PreBuildEvent of
attrib -R “$(TargetDir)*”
but couldn’t see it running during the build
Alex
Odd. So .config.exe gets made non-readonly correctly, but .txt does not? That’s weird, because they all go thru the exact same process…
EBuild does not support Pre and Post Build events right now. It’s on the todo list, but I need to figure out a good way to make this work cross-platform.
So I guess quite a lot has changed since build 2305, as that seems to be the last version not to exhibit any of these issues
Alex
Fixed, thanx for the follow-up. turned out that CopyToOutputDirectory files hit a slightly different code path that actually tried to (unnecessarily, or actually even wrongly) delete the old one before copying the new one, and it failed on that.
Hi Marc
Sorry to say, build 2357 still has problems with Read Only files
Alex
Obviously, since that was created (Friday), well before I fixed this yesterday (Saturday)… 
Uploaded a new version for you, now.
Thanks, have just tried it and no more Access Denied’s.
Next issue seems to be that files/dll’s are not carried over to final dest path
Below shows a diff between a build using 2358 (left) and 2305 (right)
The missing files are from referenced projects
Alex
I’ll need a bit more detail that that. What .dlls are those? Are they directly referenced by your project? Are they set to Copy Local?
Seems there must be slightly different behaviour in the earlier builder, in that if a reference didn’t have a element it would copy the dll, if it wasn’t in the GAC, this is no longer true for the current builder.
You now have to explicitly set the Copy Local to True,
But there is still an issue in that if say Lib1 has a Copy Always file and then you use Lib1 in Lib2 the Copy Always file in Lib1 doesn’t get copied to Lib2’s output dir, which it used to do
Hope this makes sense
Alex
it should, if you use project references, and does in my tests. i’d need a concrete testcase that shows where it wouldn’t work.
Attached is a solution with 2 projects, the file CopyAlways.txt from Lib1 does not appear in Lib2 Bin directory
TestRefs.zip (12.5 KB)
Alex
Ooookay, but that’s not the same issue as indirect references not being copied, which you originally reported above.
That behavior is (right now) entirely as designed. Referencing an assembly with CopyLocal only copies the assembly (and debug symbols/XmlDocs), nothing else.
As I explained, originally, there seems to of been quite a few behavioural differences since 2305, which means things that used to work, no longer work. So now if I need to use the latest compiler, I have to make source changes as well, so you should provide all the breaking changes so I can make all the appropriate fixes, which to be honest isn’t ideal
Alex