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.
Related
I'm currently working on a project using the "Microsoft visual studio installer Projects" to create an installer package out of the project output.
To do that I added the Project primary output to the application folder of the "MSI file system".
Unfortunately the setup project keeps adding junk files to the installer package out of nowhere. For example it keeps adding some extension called "DevExpress", which seems to not be referenced anywhere in the source project. It also kept adding additional .exe files even though I only referenced some .dll files.
Some references are even duplicates!
These are the detected dependencies according to the setup project:
This are the references of my project:
What I see when I manage the references of the source project:
I had to manually exclude the files but that can't be a solution because it still bloats the installer from 9 MB to 30 MB which is no option.
Any way to fix this? Or is there a way to at least see why those files are being added?
I think I have various beads on why this may be happening, but I can't quite put all the clues together.
We were building an ASP.NET app in VS 2019 with a nuget dependency (Microsoft.Data.SqlClient.SNI.1.0.19235.1 if it matters). I've used msbuild -t:package and in VS 2019, it would spit out bin\x86 and bin\x64 folders with the DLL from that nuget package. That package step would spit out a zip file and opening that up you can see the x86/x64 folders in there.
We upgraded to VS 2022 and the CPU arch folders are no longer there. I can see them get created in the working directory, but not in the package output.
Nothing in the project has changed. It's set to target "AnyCPU" and Framework 4.6.2. The command we're using to build hasn't changed either. As far as I can tell, it's just the upgrade to VS 2022.
I know VS 2022 is now 64-bit native, so I have a suspicion that's in play here. Any ideas on why those CPU-architecture folders are no longer included in the zip package? And how to get them back in there?
Thanks!
According to your description I make some test, hope it can help you:
Check your Configuration Manager under Build in the menu and add new Platform you need.
Build the project in Batch Build under Build in the menu.
We can see that .dll files are created in the same path so it will be covered.
Open the project file.(Right click on the project and Unload Project then right click again an choose edit project file)
You can see code like this:
Change the OutputPath to “bin\x64\Debug\”, ”bin\x64\Release\” and so on.
Reload the project and rebuild the project in Batch Build.
About how to Pack multiple platforms into one package you can see this(Pack multiple platforms into one package, using dotnet pack ).
If it helps anyone, since my problem was specifically with the SNI.dll not being emitted in the x64/x86 folders, my workaround solution was to upgrade the Microsoft.Data.* libraries to a newer version. The x64/x86 folders are still not emitted, but I now see Microsoft.Data.SqlClient.SNI.x64.dll and Microsoft.Data.SqlClient.SNI.x86.dll files in the root bin folder.
It doesn't answer the original question, but at least it got me moving.
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.
As an example, I'm trying to add a reference to WatiN in Visual Studio 2008. I download WatiN and I have a folder on my desktop containing 5 files:
WatiN.Core.dll
WatiN.Core.xml
Interop.SHDocVw.dll
Microsoft.mshtml.dll
WatiN.Core.UnitTests.dll
WatiN.Core.UnitTests.dll.config
I can add my reference to WatiN.Core.dll and start coding in Visual Studio. But I have some questions:
Can I now delete the folder on my desktop? Were the files copied to the project bin?
What happens when I check my project into source code and another developer checks it out? Does he/she have to have the same folder on their desktop.
My thought was to create a lib folder in the project and reference the files in the lib folder. This folder will get added to source control so that everything should work for the next developer. But I have some questions about this solution:
Do I need all 6 of those files?
I believe the .config files have something to do with intellisense, but the project will build and run without them right?
How do I know what files to include apart from the WatiN.Core.dll. The project builds and runs with only WatiN.Core.dll and Interop.SHDocVw.dll. How am I meant to know what the dependencies are?
Any insight is much appreciated.
Adding a reference does just that. It adds a reference, so if the reference is to your desktop folder other developers will not be able to see the files. Also, if you delete the files you will have dangling references in your project. In general, don't reference files on your desktop.
Making a lib folder in the same source control tree as the project as you have suggested is a much better solution. Visual Studio will store the references as relative paths enabling other developers to compile the project.
You will have to study the documentation for the WatiN library to know which files are required by your application. You should not delete the .config file as it is not related to intellisense.
I would create a developement tree with all source files, library files, tools, docs, resources so that any developer can get a working project straight from source control without having to search for references.
Having referenced DLLs in a lib folder means that projectA is able to use version 1.0 of the DLL and projectB is able to user version 2.0 of the DLL.
When the solution builds it will get the DLLs from where they are referenced. If it cant find them the project wont build.
Have a look at the following articles.
http://www.codeplex.com/treesurgeon
As for which dlls you need to reference, you can go the way of only referencing what you need.
WATiN needs the WATiN.Core.dll and the Interop.SHDocVw.dll in order to run. As others have suggested, it's best to have a lib folder in your source control tree for external libraries so everyone can use relative references.
TreeSurgeon, mentioned above, is a good tool or you can at least use their folder structure as a model.
The Watin.Core.xml file should give you intellisense if you put it in the bin with the dll.
I believe you can only delete the folder if you are referencing the file directly from the bin folder (cut and pasted it there). If you are referencing the file from the folder than I believe you need to keep it there.
You may run into problems deleting the other files if the dll your referencing, references the classes in the other dll's.
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.