[RESOLVED] Build - Copy files

For years I have performed the following steps when testing .DLL's

1. Open the .DLL project being tested (e.g. dbCommonLRX.dll)
2. Create a forms app with a button. and a reference to the .DLL
3. --
4. In the button click add enough code to test the .DLL
5. Run the app. Examine results. Close the app
6. --
7. for arguments sake the .DLL had to be fixed
8. switch to the .DLL project, make changes and rebuild
9. Continue steps 5 - 8 until results are correct

Today I get errors(see below) at step 8 when building the .DLL. If I close the app I don't get errors.

Errors fron .DLL build:

Could not copy "obj\Release\dbCommonLRX.dll" to "bin\Release\dbCommonLRX.dll". Exceeded retry count of 10. Failed. dbCommonLRX

Unable to copy file "obj\Release\dbCommonLRX.dll" to "bin\Release\dbCommonLRX.dll". The process cannot access the file 'bin\Release\dbCommonLRX.dll' because it is being used by another process. dbCommonLRX

We were off Tuesday. On Monday the above worked.

I have restarted my PC to no avail. I am just at a loss why this started happening.

I'm not sure what you mean by:
1. Open the .DLL project being tested (e.g. dbCommonLRX.dll)
If you somehow open the dll then it will be used and get that error. I guess you mean something else.
Is this a C++ dll or a .net dll? You are using dllimport? Maybe that somehow blocks the whole process.

I've followed those steps MANY times, without encountering the specific error you are seeing. Have you tried wiping out the Obj and Bin folders for the dll? That has never solved anything for me, but it's SO easy to do that it's worth a try. I'd say that something just got 'confused', and deleting those two folders is the software equivalent of whacking the monitor: It likely won't help, but it feels good.

EDIT: I should add that while I haven't gotten that particular error, working with a dll in one project and the main app in another, which I do frequently for a plugin system, does have a tendency to get things out of sync. However, restarting VS has always been sufficient to fix things, for me, and those were errors between the two projects, whereas you are talking about an error within a single project.

Some things.
Don't have Visual Studio here so I can't remember the etymology. There is some options on the debug menu that will clear the solution and refresh it - rebuild it. I can't remember their names.
Also what happens if you try with debug instead of release?

Quote:

---

Originally Posted by sapator

I'm not sure what you mean by:
1. Open the .DLL project being tested (e.g. dbCommonLRX.dll)
If you somehow open the dll then it will be used and get that error. I guess you mean something else.
Is this a C++ dll or a .net dll? You are using dllimport? Maybe that somehow blocks the whole process.

---

I have the test app project open and the .DLL project open.

I have tried deleting the obj and bin files, restarted VS, my PC. None of this works.

I don't recall making any changes to any options, and I'm old and who knows...

Quote:

---

Originally Posted by dbasnett

I have the test app project open and the .DLL project open.

I have tried deleting the obj and bin files, restarted VS, my PC. None of this works.

I don't recall making any changes to any options, and I'm old and who knows...

---

I also tried Repairing Visual Studio.

This may be relevant....or at least easy to try:

https://social.msdn.microsoft.com/Fo...lstudiogeneral

Quote:

---

Originally Posted by Shaggy Hiker

This may be relevant....or at least easy to try:

https://social.msdn.microsoft.com/Fo...lstudiogeneral

---

I have tried most of those, except for modifying the prebuild.

Usually when I'm working on a setup like that, I'll put the two projects into the same solution ... then from the app side - which is usually only a test harness app anyways - Add Reference... but then instead of referencing the DLL directly, I create a project reference. The only time then when I get problems is if I stop the project, make a change and then hit Run again too quickly and the IDE doesn't keep up. But for 99% of the time, it works.

-tg

Quote:

---

Originally Posted by dbasnett

I have tried most of those, except for modifying the prebuild.

---

I tried turning off Indexing and virus protection also.

Sorry don't have a solution but please post back if you find the answer. I've had that situation several times. Sometimes deleting the Obj and bin folders solve it but other times I never could solve it. so I had to create a new project and import the items from the other project.

Quote:

---

Originally Posted by dbasnett

I tried turning off Indexing and virus protection also.

---

And it gets worse... I have a web page (.ASPX) app that I can only run once in visual studio. If I make changes I have to close the project, delete the obj / bin folders and then try again. Same error copying obj to bin...

Are you by any chance targetting .NET Core?

I had the same Once, I used a pre-build event but not sure if that would work in 2012, https://social.msdn.microsoft.com/Fo...expressinstall

Quote:

---

Originally Posted by ident

Are you by any chance targetting .NET Core?

---

There is a reference to it, System.Core. I had to look.

It seems to be there by default.

Quote:

---

Originally Posted by dbasnett

There is a reference to it, System.Core. I had to look.

It seems to be there by default.

---

If I take the plunge and upgrade to 2017 will I have to recompile everything?

Well, that depends on your project. Just found something close to what I was mentioning about core.

https://developercommunity.visualstu...ng-builds.html

Well, 2012 is the ugliest version of VS. 2017 should be able to simply open 2012 projects....at least I think that worked that far back. In earlier versions, if you opened a project made in an earlier version, it converted the project in such a way that it was a bit of a nuisance to ever open it in the original VS version, again. That changed with either 2010, 2012, or 2013, where later versions could open earlier versions...back to some point, and I think that point was one of those three, in which case opening it with 2017 shouldn't require much of anything....except that I don't remember how far back 2017 will open without changing the project.

What annoys the heck out of me with 2015 and 2017 is that MS brought VB and C# together on one point in the worst possible way. Intellisense was always broken for C# relative to VB. There are two ways the languages could have been converged on that point: Fix C#, or break VB. Guess which one they chose. Intellisense in VB is now MUCH less intelligent and helpful than it used to be. Other than that, I do like VS2017.

The only migration issue I have ever had with 2017 is with a driver written in C. Broke the project beyond my skills, but I am not a C programmer.

Putting this in the pre-build event is a workaround.

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"