Nie można skopiować odwołania do pliku.dll do bin / reference.dll. Proces nie może uzyskać dostępu do referencji do pliku.dll, ponieważ jest on używany przez inny proces

Użyj ProcessExplorer Aby dowiedzieć się, który proces ma otwarty plik i stamtąd przejść.

Jeśli proces obecnie używa tych DLL, nie można go usunąć i ponownie zapisać. Będziesz musiał zabić lub w inny sposób zatrzymać proces za pomocą tych bibliotek DLL podczas kompilacji.

Walczę z tym problemem od lat!

Próbowałeś dodać to do swojego PREBUILD eventu?

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

Zobacz to, aby uzyskać więcej informacji: http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project

Oto kolejny wątek, z kolejnymi rzeczami do wypróbowania...

Http://social.msdn.microsoft.com/forums/en-US/Vsexpressinstall/thread/5b71eb06-5047-483d-8fd3-b75c102d41e9/?prof=required

Zadziałało dla mnie następujące zdarzenie pre-build:

if exist "$(TargetPath).locked.bak" del "$(TargetPath).locked.bak"
if exist "$(TargetPath).bak" del "$(TargetPath).bak"
if exist "$(TargetPath).locked" ren "$(TargetPath).locked" "$(TargetFileName).locked.bak"
if exist "$(TargetPath)" ren "$(TargetPath)" "$(TargetFileName).bak"

Zauważyłem w moim przypadku, że pliki 2 są tworzone i nie można ich usunąć. Możesz jednak zmienić ich nazwy (i nadal są używane, jeśli spróbujesz je usunąć). Przy następnej kompilacji, przemianowane pliki nie są już używane (blokada usunięta) i mogą zostać usunięte, co robi powyższy skrypt, po czym może bezpiecznie zmienić nazwę nowych zablokowanych plików, więc nie będzie problemów w generowaniu kompilacji wyjście.

Inne zdarzenia pre-build zamieszczone tutaj i w innych miejscach nie pomogły mi bardzo (działały tylko przy jednym dodatkowym build lub tylko kilku, zanim problem pojawił się ponownie). Więc teraz używam tego zamieszczonego powyżej do moich celów debugowania.

Chciałem tylko powiedzieć, że ten problem zaczął się ode mnie dzisiaj. (VS 2010, C#) pracuję nad tym programem od miesiąca bez tego problemu, teraz już się zaczęło. Uruchamiam VS, zmieniam kod, kompiluję, testuję i zamykam program. Dokonaj kolejnej zmiany, skompiluj i BOOM nie może skopiować pliku " obj \ x86 \ Debug \ progname.exe " do " bin\Debug\progname.exe", ponieważ if jest używany przez inny proces.

ProcExp pokazuje tylko Visual Studio (właściwie devenv.exe) za pomocą tego pliku. Jest tylko jedna instancja vs running. W moim debug \ progname znajdują się dwie listy.exe, jeden jest DLL typu, drugi jest Uchwyt Typu.

Używanie devenv / ResetSettings niczego nie rozwiązało, ale zmarnowało 10 minut na przywrócenie wszystkiego do pożądanego widoku.

Używanie PREBUILD events rename trick wymienionych powyżej rozwiązuje problem dla kilku zmian, ale przy następnej zmianie " exe.zablokowany " plik jest zablokowany i nie można go usunąć. Wtedy zmiana nazwy nie powiedzie się.

The debug\progname.nazwa pliku exe pozostaje zablokowana nawet po zamknięciu projektu.

Zamykanie VS, ręczne usuwanie plików w folderze debugowania, otwieranie VS i moje rozwiązanie, a następnie Build->Clean rozwiązanie wydaje się działać dla mnie, przynajmniej działa teraz po tym, jak zrobiłem wszystkie te rzeczy.

Mam nadzieję, że to pomoże - rwg

Niestety nie miałem szczęścia z wydarzeniami pre-build. W typowym stylu IT Crowd udało się zamknąć Visual Studio i otworzyć je ponownie.

Easy fix Dla Windows 7: Uruchom usługę "doświadczenie aplikacji". Wyszukaj "usługi" w "Panelu sterowania".

-Martin

Jeśli masz Visual Nunit, musi to być blokowanie pliku dll.

1. Close VS
2. Idź do taks managera, wyłącz proces Visual Nunit
3. teraz otwórz VS i zbuduj projekt

Witam od jakiegoś czasu mam ten sam problem. To bardzo irytujące.

Mam łatwiejsze, ale nie tak skuteczne rozwiązanie problemu. Czyszczenie projektu lub rozwiązania rozwiązuje problem.

Po prostu przejdź do \Debug \ bin i usuń wszystkie .pliki dll.

Działa świetnie dla mnie.

Miałem taki problem w projekcie www z systemem.Www.Rozszerzenia.dll z folderu Microsoft Reference Assemblies. Ustawianie" Copy Local " NA false we właściwościach reference naprawiło to.

Możesz pobrać doskonały program Sysinternals Handle . To powie Ci, które procesy mają blokadę danych plików.

Jeśli jest to program zewnętrzny (np. skaner antywirusowy/indekser) to powinno to pomóc. Jeśli tylko zgłosi Visual Studio (devenv.exe) jako winowajca, wtedy będzie mniej pomocny!

Zakładam, że już wiesz, że to VS2008 blokuje pliki. Możesz spróbować uruchomić MSBuild z linii poleceń i sprawdzić, czy problemy znikną. Niestety program Visual Studio może zablokować pliki, gdy nie powinien, w niektórych trudnych do przewidzenia scenariuszach.

Blokady plików to tylko część pracy z Visual Studio. Nie ma dobrych sposobów na obejście tego problemu.

W Visual Studio 2008 pojawił się konkretny błąd, który został naprawiony w SP1, który może być Twoim problemem. Występuje, gdy odwołujesz się do osadzonego pliku JavaScript i powoduje problem, który widzisz. Zobacz tutaj Po Więcej Szczegółów.

Miałem problem z simillarem rozwiązaniem dla mnie było spojrzenie na *.plik csproj i pod znalazłem brakujący plik więc i poniżej był poprawny więc po prostu usunąłem linie i działało od razu

Usuwanie następujących linii z mojej aplikacji.config rozwiązał to dla mnie - używam VS2010.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
          <assemblyIdentity name="nunit.framework" publicKeyToken="96D09A1EB7F44A77" culture="neutral"/>
          <bindingRedirect oldVersion="0.0.0.0-2.5.7.10213" newVersion="2.5.7.10213"/>
      </dependentAssembly>
  </assemblyBinding>
</runtime>

Sprawdź, czy biblioteka DLL użytkownika i aplikacja odwołująca się do biblioteki dll są adresowane do tego samego. NET framework. Miałem przypadek, w którym ramy były różne, co spowodowało ten problem.

Zdarza mi się to czasami, gdy używam Visual Nunit do testów jednostkowych.

Wydaje się, że proces ' VisualNunitRunner.exe ' blokuje .pliki dll w katalogu docelowym.

Użyłem Unlocker aby znaleźć proces, zabić go lub odblokować pliki.

Miałem podobny problem i mogłem go rozwiązać zmieniając ' AssemblyInfo.cs '

Visual Studio Build fails: nie można skopiować pliku exe z obj \ debug do bin \ debug

Pliku nie można usunąć, na szczęście można zmienić jego nazwę i przenieść. Więc utworzyłem prebuild batch (używając daty i czasu jako losowego ciągu, mogą być łatwiejsze sposoby):

For /f "Tokens=2,3,4 Delims=/. " %%i In ("%Date%") Do @(
  Set Month=%%i& Set Day=%%j& Set Year=%%k
)

set ActDate=%Year%-%Month%-%Day%

For /f "Tokens=1,2,3 Delims=/.:, " %%i In ("%Time%") Do @(
  Set Hour=0%%i& Set Min=%%j& Set Sec=%%k
)

set ActTime=%Hour:~-2,2%-%Min%-%Sec%

move c:\MyProject\bin\Debug\myproject.exe c:\garbage\%ActDate%_%ActTime%_myproject.exe

Właśnie mnie to spotkało. Musiałem zabić wszystkich devenv.procesy exe (było ich 3 po zamknięciu okna VS 2010).

Usuń pliki binarne z folderu bin\Debug i przekompiluj je. To mi pasuje!!!

Ten problem występuje zwykle, gdy zmieniasz projekt z jednego katalogu do drugiego . W przypadku błędu kopiowania cienia możesz dodać tę linię w swoim web.config.To fix this follow the following

W sieci.plik konfiguracyjny jeśli istnieje coś takiego jak

<hostingEnvironment shadowCopyBinAssemblies="false" />

Zmień to na

<hostingEnvironment shadowCopyBinAssemblies="true" />

Używałem Visual Studio 2012, gdy zaczęło się to dziać na 7-letnim rozwiązaniu(po raz drugi lub trzeci: byłem już na tym pytaniu).

Ostatecznie przypomniałem sobie, że wczoraj wieczorem zainstalowano aktualizację zabezpieczeń i została skonfigurowana, gdy uruchamiałem mój komputer dziś rano - (połączone czy nie? No Idea) - więc, ponownie uruchomiłem Windows, i voila, to wszystko działało jak magia ponownie.

Dzięki MS za więcej mincing umysłu.

Ja też mam do czynienia z tym problemem. Najpierw staram się usunąć .dll ale pokazuje Odmowa dostępu, a następnie zamykam mój VS i po otwarciu działa dobrze.

Podobne do odpowiedzi Benoita, ale nie wymaga instalacji żadnego narzędzia, możesz użyć polecenia tasklist (Menedżer zadań) w wierszu poleceń z przełącznikiem '/ m', aby uzyskać listę procesów za pomocą dll:

Tasklist / m mylocked.dll

Widziałem kilka postów wskazujących, że musisz to zrobić z katalogu biblioteki DLL, ale nie znalazłem, że tak jest.

Możesz również usunąć foldery bin i obj we wszystkich projektach w rozwiązaniu, a następnie odbudować rozwiązanie.

Otwórz swój projekt w Eksploratorze kliknij właściwość folderu bin i odznacz właściwość tylko do odczytu, która działa w moim projekcie Xamarin forms

Wreszcie jak to naprawić. Dzieje się tak, ponieważ pierwszy debug exe nadal działa. Następnie przejdź do Menedżera zadań - > Zakładka proces - > [Nazwa projektu exe] Zakończ proces exe