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?
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
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.
This is in VS2010 ...
I can't figure this out, but my assembly is not outputting a Properties folder with AssemblyInfo and the other bits that go along with it. I checked the csproj file and the following:
<AppDesignerFolder>Properties</AppDesignerFolder>
Is present, yet on build nothing gets generated. What am I missing?
The things in that folder are not generated during a build, they should exist and be included in the build. When you create a new solution/project, those files will be created. If you delete them, then you'd have to manually recreated them or copy them from a separate project (and update them).
The AppDesignerFolder just tells Visual Studio where it should look for some of the UI elements that can be used to update the files there (i.e. the version information in AssemblyInfo).
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.