I work on the project that I have inherited from another developer. It is mix of VB.NET & C#.
Solution is made of multiple projects: Config(start-up project),Common,Agent + project StdPlugin under Plugin folder. (Plugins are .dlls that are loaded during runtime).
For non-plugin projects, output path is set to bin\Debug\. For Plugins projects output path is set to Config\bin\Debug\Plugins.
After the project is compiled, Config\bin\Debug\ has all .dlls +.pdbs and .exe for all my projects. However, Config\bin\Debug\Plugins also contains copies of all project .dlls + .pdbs and .ddl + .pdb for StdPlugin project. In other words, I am getting duplicates. On top of that, when I run Build->Clean Solution, Config\bin\Debug\ is being cleaned out, but Config\bin\Debug\Plugins is not.
Some clarifications: 1. Project is build for debugging. 2. I noticed above issues while investigating The source file is different from the module was build issue that affects the Reader project. It would not stop on breakpoins in Reader project.
Related
I have 3 C# projects, A (WPF application), B (class library), and C (class library), such that A references B, and B reference C. Project C needs to call some native methods from a C++ DLL via P/Invoke. I added the native DLLs to the C# project and marked them a "Copy to Output Directory". When I build my solution, the native DLLs show up in the output directory for Projects B and C (correctly), but not for Project A. Is there a project setting that allows these to be copied by any project that ultimately references Project C (even if not directly)? Or do I just need to post-build event on Project A to copy this files to my application output folder?
I've looked at Dependencies of references not copied to output directory, but this was referring to project references, so I'm wondering if there is a solution in my case.
I also considered embedding the native DLLs as resources and modifying my DLLImport as in this MSDN article: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx. But I get an E_ACCESSDENIED error (I've seen others with this same issue as well, as well as some concerns about triggering antivirus behavior when extracting the DLL to disk). I also noticed the article mentions linking the resource, rather than embedding it. Is this something I need to do as an MSBuild task, rather than through some project properties?
Worst case, I could just add a post-build event to my WPF application that copies the native files, but it would be nice if Visual Studio would recognize that these files should be copied.
I solved this by customizing the output for debug/release mode compiles (on the project properties window) so that all of my projects outputted to the same folder... Much like how an ASP.NET application is published where all DLLs end up in a single /bin folder. That fixed my issue.
I have created a Setup Project in VS2010 for my VC++ project and I have it generating a setup file and it includes Primary Output, Content Files, Documentation files and Resource Sattelite DLLs from my VC++ project. My VC++ project is multilanguage and hence includes language DLL files in subdirectories. My issue is that the Setup Project does not include these language DLLs (nor their directories into which they must be placed).
I would have thought that these DLLs were included in the Project Output but they are not. :-/
I know I could add them manually by referencing the files directly, but that means including a absolute reference which I would rather not do. Also, a fixed reference means Release/Debug versions of the file are not handled (only one of them is use regardless of project setting).
Suggestions?
Edit: I have now tried Setup Project, InstallShield LE and WiX. None of them include the localization dll's into the setup project (only managed a working setup with Setup Project, but could see that the other installers did not include the required dll). I can't even fint any reference to this being a know bug and I have really tried hard to find a solution to this.
Found it over there:
C# Creating a setup for multi-language
It worked. I hope it is what you were searching for.
When building managed code Visual Studio correctly (and recursively) copies dlls of referenced managed projects to the output folder of the project being build.
However, if one the of those references is a managed DLL that depends on unmanaged dlls then these unmanaged DLLs are not copied to the output folder, even though their corresponding projects in the same solution and are listed as dependencies of the managed DLL.
I realize that this problem can be resolved by having all projects use the same output folder. We already do that for most projects, but we prefer to keep unit test output folders separate, causing the above issue for unit tests that use a managed Dll with unmanaged dependencies.
The solution we are using right now is a pre-build event to copy the necessary DLLs but this wastes time and is error-prone as it needs to be repeated for every project that uses the managed DLL.
I would therefore like to know if there is a way to get the build system to understand that it should always copy the unmanaged dependencies of the managed DLL whenever it decides to copy the managed DLL?
One workaround seems to be to add another node to the managed DLL project, naming the unmanaged DLL and setting the Build Action = "None", and Copy to Output Directory = "Copy if Newer".
Edit: For building a C++/CLR project, I think this would work:
Add the node, and set its build tool to Custom Build Tool. Then, in the Custom Build Step page, set the Command to copy $(InputPath) $(OutDir) and the Outputs to $(OutDir)\$(InputFileName). Looks like that should work.
I need some help regarding Visual Studio solution and project organization.
I have a solution with several projects. All of them are written in C# and are compiled as libraries to be used by the GUI. Some of these libraries have also dependencies with others. For example, TestExecutive needs LoggingFramework, Communications needs LoggingFramework too.
Which is the best way of organizing? I'm thinking on a folder assemblies to hold libraries' binaries in one place. Something like:
Solution
|
|-- TestExecutive
|-- LoggingFramework
|-- assemblies
There is also another problem. One of the projects uses a native C dll. Where do I have to place this library? With the librarie's assembly or with the final executable?
EDIT:
Ok, now suppose I have the WinForms program running. I have source code and binaries mixed. Which features do I need to generate something I can distribute? I mean, with all the libraries and configuration files, but without source code. I have done this before with Nullsoft installer, but I don't know if visual studio can help you doing that.
A few things here:
When one project depends on another, you can set up that dependency in Visual Studio. Right click on a project and select Project Dependencies...
For other .NET assemblies that are NOT part of your solution (3rd party tools, etc.) I do exactly what you showed here -- I have a separate folder parallel to the projects. Then I set up the assembly reference in each of the projects with "Copy Local" set to true and it works fine.
For native C dlls, it's a little different. There is no direct reference to them in the references section of the solution explorer. The compiler isn't going to look at the dll to check your p/invoke references or anything like that. You just need to make sure the dll is part of the deployment on your top level web or winforms project. It's a content file just like a css file or image or something. Just add it as a file in the project and make sure the "Build Action" is set to Content so Visual studio knows to just copy the file as part of the deployment
I set my solution folders up a bit differently than you. At the top level I have the following folders:
\build
\lib
\src
The build folder has build scripts (NAnt, MSBuild, etc). Any 3rd party assemblies (or anything I'm not building in the solution) get put into the lib folder, in an appropriate sub-folder. For example, I'll have log4net, NUnit, RhinoMocks folders in the lib folder, each containing the files needed for that dependency. The src folder has the solution and all project files.
I like this structure because it clearly delineates between the project code and the other stuff that is required by the project. Also, I usually set up some custom build tasks to copy the resulting assemblies for my project into either a \deploy or \lib\ folder. This way you don't have to hunt in the \src\\bin\\ folder to get a built assembly or the whole project; however this seems a bit beyond the scope of your question.
Btw... I didn't come up with this structure on my own, I think I started off using Tree Surgeon and evolved my process from there.
When you unload a project in Visual Studio, any referencing projects get warning triangles on their reference to the unloaded project. I've written myself a macro to do clever stuff (detect add/remove of project and transform any references from-to file/project dependency), but I can't believe that I'm not missing something much simpler. How can the unload function be any use if I have to go around manually changing references (and it breaks the 'personal solutions/shared projects' team development paradigm).
(This question is related to answers to this question about structuring large solutions in Visual Studio - some answers mentioned having solutions with lots of projects, but 'unloading' unused projects to improve performance.)
For my projects, I create an assemblies folder which the projects automatically copy into from a set location to which other projects copy builds.
Post-build for referenced assembly's project:
if not exist "C:\builds\Project1" md "C:\builds\Project1\"
copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
Pre-build for referencing projects:
if exist "c:\builds\Project1\" copy "c:\builds\Project1*.*" "$(ProjectDir)assemblies"
The project file points to its assemblies subfolder for references so even if the source projects are unloaded from the solution, the last-built assemblies will be used without the performance problems of having the whole project in memory while developing.
What are the advantages of having projects in the same solution if you use file references?
If your app.exe uses utils.dll and you change the code for utils.dll, then if it's in the same solution VS will notice the dependency and recompile both. If it's not in the solution you'll have to jump out, recompile utils.dll seperately, then jump back in and recompile app.exe.
This becomes either more or less important depending on how many other dll's your exe is referencing, and how often they change (in team environments shared dll's change often in my experience).
There is also the side effect that if you have 100 projects in VS it will take a long time to process them all just to figure out if they need recompiling or not.
Unloading projects is meant to be a temporary action so you can edit the actual project file as XML (text). If you want to completely remove a project from your solution, you should use the "Remove" menu option, which will take care of removing any references to that project.
One advantage to using project references is that it allows you to easily debug through the code. It also automatically ensures that you are using the correct configuration build (ie, if you are building in "Debug" mode it will use the Debug version of the assembly). That being said, you loose some determinisim about which version/build of the dependent project you will pick up - project references mean you always use the latest.
Yes, for Visual Studio to determine build dependencies it must be able to see and build all of the projects which would mean project references.
I've just had a eureka moment reading through MSDN doc on structuring solutions and projects.
What I hadn't noticed is that in a multi-project solution, the context menu in the Solution Explorer proposes a Project Dependencies popup. Here you can define the project dependencies manually, if you haven't defined them by project references between projects.
See here (MSDN link, so will self destruct after a few weeks)