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.
Related
I'm a bit of a noob on that topic so I'm searching for help. I need to install this library (https://github.com/twcclegg/libphonenumber-csharp) for a unity project where I need to check phone numbers.
But as I always made simple games in unity I really don't know how to do that and I don't really know either what to search to find an answer.
If anyone of you knows how to do it, it will really make my day.
Thank you
Once do a build on a project you want to use in Unity, then find the DLL output from the build. I recommend you do Release Builds, but for now if you are not familiar with Visual Studio just use what you were able to build. If there are multiple directories then you only need one - the best one to use would be any labelled ".NET Standard" which it seems you have a .net standard 2.0 directory.
Go to your Unity project in the Assets folder, and if there isn't already a Plugins folder create one. Then in Assets/Plugins create a folder named whatever you want for the library - in this case PhoneNumber would be fine. So you would have Assets/Plugins/PhoneNumber and you would copy/paste the contents of your NetStandard2 folder there.
In the end you should have Assets/Plugins/PhoneNumber/PhoneNumber.dll
As soon as you have that dll, you can switch back to Unity and see if it worked by checking the Unity Console for any Errors. You might receive errors saying it could not load the DLL. Almost always if it can not load the DLL it is because of missing dependent DLLs - which is why I said to copy the entire folder contents inside the "NetStandard2" folder since it may contain more than just PhoneNumber.dll - it may have it's necessary dependent dlls also.
If not, you can read the error output and hopefully get a clue as to what dependent dlls are missing. You can also expand the Dependencies in Visual Studio.
Typically the DLL failing to be loaded in Unity is because of missing dependent DLLs. Expanding the Dependencies, which is found under the project name in the Solution Explorer window on the right side of Visual Studio, will show you what libraries it requires. Most of what you see under dependencies (if not all) will require a similarly named dll. Under the netstandard2.0 dependency I see System.Collections.Immutable - so you may need a System.Collections.Immutable.dll which should (usually) be in the output folder when you build the project. You would also need that dll in Unity in your PhoneNumber folder along with PhoneNumber.dll
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.
Is there any way in Visual Studio or something else that allows the programmer to export the main executable with the dynamic libraries without the need to copy manually some important .dll's from system32 or somewhere else?
For example, OpenGL programs need (beside glut32.dll and opengl32.dll) msvcr100.dll to run.
Is there any efficient or professional way of deploying applications that use dynamic libraries?
There are two ways to do this in Visual Studio Setup and Deployment project:
Project - Properties - Prerequisites.
Project - Add - Merge Module.
The second way is more flexible and may be used for third-party merge modules, not included in Prerequisites dialog.
Of course, if you don't have Setup and Deployment project yet, create one for your application.
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)