I get this error in Visual Studio 2008 when developing a ASP.NET Web Application Project.
Unable to load referenced library
'Path-to-DotNetNuke\bin\file.dll': The
process cannot access the file because
it is being used by another process.
This is a DotNetNuke project with multiple modules. IIS loads all assemblies from /bin folder under the application root.
The projects in the solution are in their respective /DesktopModules/ProjectName folders and compile to a bin folder under the project.
The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok. This is really annoying when recompiling and testing the whole solution. You have to restart Visual Studio between every recompile.
I couldn't find any file locks with Process Explorer when Visual Studio shows this error.
[UPDATE] There is an old MSDN document that tells you not to build all DLLs to a single folder if you reference any over 64KB DLL there. Particulartly, the document says:
It causes the build process to fail
with file lock errors when a
referenced assembly exceeds 64 KB in
size.
We do have references to over 64KB DLLs in /bin folder and copying recompiled DLLs there seems to trigger this, at least with VB IDE's background compiler.
The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok.
I would suggest setting the output directory of each of your projects to be the bin directory of the DotNetNuke website. This will help you to avoid the manual step of copying files altogether.
To set the output directory of your project: Right click on your project in Solution Explorer and select properties. Select the build tab, select All Configurations (at the top) and set Output Path to "..\..\bin" (near the bottom). This assumes your project file is in it's typical spot within the module's home directory (e.g. DesktopModules/YourModule/YourProject.csproj) otherwise you can navigate to your web site's bin directory with the adjacent browse button.
Related
I have developed an opencv application using windows form and C#.
The opencv packages I got from the Nuget packages manager (EMGU.CV and ZedGraph).
Everything works fine in visual studio, but when I publish the project and install the program in my machine, it throws an exception when I click a button that performs some opencv operations.
I guess the opencv packages didn't come along with the final published project, so how do I do to make it export when publishing, I thought it would be an automated process, I have already used other nuget packages and I had no problem with it.
What Am I missing here?
After some days waiting for an answer, and looking for solutions, I've figured it out how to solve this issue.
I came across this question:The type initializer for 'Emgu.CV.CvInvoke' threw an exception
Which led me to this: http://www.emgu.com/wiki/index.php/Download_And_Installation#The_type_initializer_for_.27Emgu.CV.CvInvoke.27_threw_an_exception.
More precisely this part:
First of all, I don't know why the compilation runs fine inside visual studio enviroment and why not when publishing the project as it is. For some reason, the Nuget packges are not enough for publishing the project, you need to add the .dll files manually yourself (not sure why this occurs once I have worked with Nuget packages before and this workaround was not necessary).
To find the .dll files you go to your project directory, then you go to bin\Debug\x64 or bin\Debug\x86 (depends on which operating system you are targetting - 32 bits or 64 bits -in my case I added all .dll files from x86 folder, I guess you can add from both folders if in doubt).
The Debug folder of your project is build every time you run the project inside Visual Studio enviroment, so if your Debug folder is empty then you just need to run the project one time to be able to find the auto generated files inside that folder. Just a side note here, you can use either the Debug or the Release folder inside bin, just remember to check if you compiled the project in Debug mode for Debug folder, or Release mode for Release folder, otherwise the desired folder will be empty, as explained before, I found no differences between the files generated, I added the dll files from Debug\x86.
Once you have located the .dll files, you go to Visual Studio, right click on the project in the Solution Explorer tab, then Add ---> Existing Item.
Go to the folder where the .dll files are, select all and click Add.
Once you have done this, the .dll file will be shown in the Solution Explorer.
Right click on each .dll file added in the Solution Explorer, and open the properties tab by clicking Properties. On the Properties tab, go to option Copy to Directory and change the field to Copy Always (the emgu documentation link provided above states to use the option "Copy if newer", but to make sure I chose "Copy always", it worked fine for me). Repeat the process for all .dll files added.
Now you are ready to go for publishing the project as it is,just remember doing this every time before publishing your project to see if no .dll files are missing, so once you got to final version of your program, run it, and then make sure to check the .dll files, it might have new ones to add or to remove.
I'm trying to publish my project as a click once application, everything builds and compiles properly and I can run the program. The issue is that during run time on the click once I keep getting The type initializer for 'Emgu.CV.CvInvoke' threw an exception. When launching the application from Visual Studio in debug or release mode I have no problems. I've determined that this is because the x86 and x64 folders from my nuget package were not being copied into the application files.
My application also doesn't directly reference emgucv. They way it works is that I have my MainProject reference Library A which references Library B which has the nuget package for emgu CV.
They all target Any CPU and run .Net Framework 4.7
I have also added the following post build events to copy unmanaged dlls:
MainProject:
copy "$(SolutionDir)LibraryA\$(OutDir)." "$(TargetDir)" /d
Library A:
copy "$(ProjectDir)Unmanaged*.*" "$(TargetDir)"
copy "$(SolutionDir)LibraryB\$(OutDir)." "$(TargetDir)" /d
When I look at the application files where things get published to I don't see either the x86 or x64 folders that include the cvextern.dll emgu depends on.
I feel as though I'm missing something important that is preventing CvExtern from being copied automatically.
Updating from version 3.1 to 3.4 did not help either.
I have found one solution by copying the folders from the package's folder into the main project and setting them to Copy Always however that feels more like a work around then a solution because I feel as though I shouldn't need to reference the files from multiple projects.
In Visual Studio create new project folders for x86 and x64 in the project that is being published. Copy the Emgu dll(s) from the bin folder into the new solution folders. Include the files in the project as Content and set "Copy to Output Directory" property to "Copy If Newer" for each file. This should result in publisher including the files in the deployment and placing the files in the correct relative path.
I have some videofiles in our SVN repository alongside the sourcecode of my application. After checking out, the visual studio project is built using cmake.
my code needs to load the video files and it works well when running the application out of visual studio - but when the exe file in the release/debug folder is doubleclicked, it crashes because the relative paths are not right anymore. aparently when running it from within visual studio, the folder where the .sln file lies is considered the root of relative paths.
how can I refere to the videofiles from the code, such that the application works if i run it within visual studio as well as if i double click the exe in the release/bin folders, without to duplicate the videos? (they are quite big)
I need to do this because I have to hand in my application such that it can be compiled and run out of the box as well as executed without visual studio.
You can change your project's settings to make the IDE's behaviour match double-clicking on the executable, and then fix your relative paths.
For VS10/VS11, in the project's properties page, at the top select All Configurations from the Configuration: list.
Then select Configuration Properties->Debugging and set the Working Directory to $(OutDir)
Beware that running the executable from the command prompt in a directory other than $(OutDir) will still fail.
In Resharper, there's an option to navigate to sources from symbol files. If I enable downloading, the navigation works - I can step into the code of Console.Writeline and so forth.
However, I have already downloaded the entire reference source - is there a way to direct Resharper to that source, so it doesn't download unnecessarily?
I've configured the reference source according to the instructions on the site
It's not possible at the moment. Please vote/watch http://youtrack.jetbrains.net/issue/RSRP-126489
I was able to get this working with Visual Studio 2015 RTM and ReSharper v9.1.3 (and Visual Studio 2013). This is what I did...
NOTE: This is quirky. I'm not sure why, but sometimes the downloaded symbols have source code info in them and sometimes they don't. I had to repeatedly delete symbols from my cache and try to get the appropriate ones by attached the debugger to apps/websites and go to the Tools->Options->Debugging->Symbols and clicking Load All Symbols. I also did some source-stepping, and I had to copy the PDB files from my Symbol Cache into directories in the GAC and in C:\Program Files (x86)\Reference Assemblies. Finally, I went to the properties of the Visual Studio project and add F:\dd to the list of Reference Paths. I'm now able to right-click Navigate to Sources to most classes.
Short version:
You have to use http://referencesource.microsoft.com/symbols as your symbol server instead of the default Microsoft Symbol Server
The symbols expect to find the Reference Source files in F:\dd.
Delete all cached symbols so it pulls them fresh from the newly added symbol server.
Long version:
Configure Visual Studio according to the instructions found on the official .NET Reference Source site.
Go to Visual Studio's Tools->Options->Debugging->Symbols, stop using Microsoft Symbol Servers and use the Reference Source Symbol Server (http://referencesource.microsoft.com/symbols) instead.
Delete all of your cached symbols! The PDBs in your cache do not have any information about the source code files. Visual Studio may have locked some of them, so you may have to close it first.
Download the zipped up Reference Source file for the .NET Framework version you're working with.
.NET v4.5.1
.NET v4.5.2
.NET v4.6
Here's the tricky part. The zip file you downloaded contains a folder called Source. The symbol files will expect that folder to be F:\dd. You can open up one of the PDBs retrieved from the new symbol server you added to see what I mean:
If you have an F:\ drive, it's easy: extract the Source folder from the zip file to F:\ and rename it to dd and you're good to go.
If you don't have an F:\ drive, you create an F:\ partition or load a virtual disk. I used a mapped network drive by extracting the Source folder into the shared folder C:\Code.
Then I mapped a network drive to \\MYPC\Code:
I didn't want to rename the folder to dd, so I named it ReferenceSource and created a directory junction using Command Prompt (must run as Administrator):
cd C:\Code
mklink /j dd C:\Code\ReferenceSource
Voila. Now I have an F:\ drive mapped to C:\Code and a junction dd that points to C:\Code\ReferenceSource.
This has to do with source control, I'm using VSS and the Visual Studio 2008 plugin. When the DLL of a referenced project gets included in a project (and checked into VSS), on the next build it will fail because those files aren't checked out as part of the build process and will be read only.
I could exclude the entire bin folder and all dlls, but that is where I put my static dlls (ie. the ones that aren't rebuilt as part of the solution) and interestingly, Visual Studio treats dlls other than outputs of other products as excluded files just fine.
In VS2005, the VSS plug in didn't automatically add the output of referenced projects as files pending check in, but in VS2008, it does.
Anyone run into this issue or find a work around?
It's better to not check in the bin folders at all. Move the dependencies to a common lib folder, and reference them from there. That will make sure they're copied into the bin folder. You can then explicitly check in this lib folder.
Other files/folders to avoid checking are the obj directory and the ncb file. I'm not sure how "smart" the VSS integration is in this case.