I'm encountering a weird solution structure in my company—the different layers of the application are organized in folders (instead of in projects).
For instance, there are folders within the solution named "DAL", "BL", "WCFClient," etc. I've never seen that before, but can't quite put my finger on what troubles me about it.
Can anyone tell me if there are any cons (or possibly pros) for this folder-based organizational approach?
Here are few cons and pros for C# (.NET) projects:
Pros:
Multiple projects can cause circular reference problems if classes are not put into correct assemblies. See http://en.wikipedia.org/wiki/Circular_reference and
Why are circular references in Visual Studio a bad practice?
Multiple projects leads to multiple dll files. Handling those MIGHT be tricky if they are piling up a lot. For instance we had ~200 files in our project and TeamCity sometimes lost few files at build process. We got around of it by zipping our files before deploying them.
Cons:
Code is not modular. You cant reuse parts of it in other projects. I think this is one of biggest downsides. For instance if you want to use one class from assembly. You have to add reference to whole project.
One project can grow HUGE and cause multiple problems. Starting from name collisions (In VB.NET there are no namespaces automatically created for folders) into deep folder trees.
Searching from huge project is harder than from small one (depending how accurate the foldering is)
Related
Here's the issue I'm running into.
Project #1 - DLL
- Includes SomeCommonFile.cs file with several classes
Project #2 - Different DLL
- Includes SomeCommonFile.cs file with several classes
Project #3 - A web service
- Includes SomeCommonFile.cs file with several classes
- Includes references to both the DLL files.
So I've got the DLLs imported in just fine in Project #3, after putting aliases on the references, and "extern alias" at the top of the relevant code files.
But here's the problem when coding in Project #3: every single class in that SomeCommonFile.cs has three versions - one for each dll, and one in Project #3. Is there any easy way to structure this so that I don't have to have conversion functions all over the place (converting Project1DLL.CommonClasses.MyClass to WebService.CommonClasses.MyClass, etc)? At this point, I'm at the point where I'm going to Link Projects #1 and #2's code files instead of their DLL, just to simplify the classes, even though that sounds bad from a maintenance perspective.
The solution is to not include the common classes in each of three different projects in your solution.
If both of your DLLs need to reference some common code, and neither can reference the other, then have a 4th DLL with the common code that they both (along with the web project) reference.
Now you only have one copy of the classes, and they all play nice with each other.
I need to share Properties (AssemblyInfo, Resources and Settings) between many multiple projects inside my solution in order to decrease repetition. Projects will likely be used in other solutions, so code dependency must be minimal to allow for easy transfer.
The top method for sharing AssemblyInfo seems to be creating a solution-level "SharedAssemblyInfo.cs" file, which is linked by each project, meaning only one file exists. However it is more difficult to create shared Resources and Settings as their given designers cannot be transferred into a Solution-level folder or Shared Project.
What would be the best practice to share Project Properties within a solution in a uniform fashion, and what disadvantages of using the proposed answer be?
I have a large solution which is built daily in TFS. The solution covers multiple logical sub solutions - e.g ApplicationA which consists of projects A,B,C,D; ApplicationB which consists of projects A,B,E,F, ApplicationC which consists of projects A,C,G,H.
Currently we make a copy of the build solution file locally and unload projects we don't need to build to work on a project - so for ApplicationA we'd unload everything other than A,B,C,D.
Another approach would be to create multiple solution configurations which would only build projects A,B,C,D for ApplicationA - but I fear this would be cumbersome and the .sln file would end up huge.
The issue is that many projects are brought together into one wix package and installed together - so the main .sln file makes sense, especially from a build point of view but also debugging.
Maintaining multiple solution files doesn't seem right as when new projects are added we'd need to add them to multiple solutions. So perhaps the configuration method is the way to go, but it doesn't feel right either.
Does anybody have experience of a similar scenario, and how did you get around it?
It sounds like it would make sense to have five solution files:
Master.sln, contains all projects
ApplicationA.sln, contains projects A, B, C, D
ApplicationB.sln, contains projects A, B, E, F
ApplicaitonC.sln, contains projects A, C, G, H
It's fine to have all of those solution files in the same top-level directory.
But maintaining multiple solution files isn't feasible as when new projects are added we'd need to add them to multiple solutions.
Why is that a problem? You need to work out which applications the project is required by anyway... Create the project in the master solution (which will definitely need it) and then use "Add existing project" for the solutions which need it. It's really not that much work - and I wouldn't expect that new projects are added that often anyway. (If they are, that's an indication of a bigger problem.)
I got many .dll files for my project.
It is quite troublesome that moving a lot of .dll around for a project.
Is there any simple method to group many .dll file into one?
I heard something call dll wrapper but I cannot find out any concrete method related to it.
Can anyone give me a hand please.
Thank you very much.
By the way, all my .dll files and project are written in C#.
You can use ILMerge utility
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly.
It is quite troublesome that moving a lot of .dll around for a project.
Really? Define many. I have projects consolidating 50ü+ dll#s and you know what - it is trivial to move them. Scripts, installers all do that automatically. Including configuring a dozen build server agents with the necessary copies etc.
Really, the only time I have to copy thm around is when I deploy manually to another machine for hotfixing or manual testing. I do that quite a lot at the moment (develop local, copy / paste the folder content to another machine to run tests - faster and closer to the database). Trivial. if it gets more work, I put in a little script. Trivial again.
Being a programmer is not about just knowing how to write some small classes, it also involves optimizting your environment a little. In times of CI (Continuous integration) and pretty much mandatory installers knowing more than just your programming langauge is a must. And then this is trivial.
You could unite your DLLs into a single multi-module assembly, or just create one giant C# project that includes all the DLL source files and compiles everything into a single DLL.
However, what's the problem with moving several DLLs around?
I've got a bunch of .dll assemblies, such as HtmlAgilityPack and MoreLinq. Where am I supposed to put these files? I usually toss them somewhere in my Projects folder, but then I'm always digging around for them. Is there a standard place to put them?
There's no standard place to put them, but make sure you:
Put them in one place
Include them in source control.
I put all my required dll's in a top level directory in my solution called "Dependencies", parallel to the project folders. I have them in source control such that when new developers check out the solution, it all compiles and works right off. It's the only way to go.
I include only the .dll files absolutely needed. This keeps it light, which is good, but then when I find some other part of MVC Contrib or whatever that I need, I have to go find the unzipped directory, which might not even be on my computer! Others put entire library directories (readme.txt and all) as part of their source control linked to the solution. This ensures you and future developers will have everything they need, but adds a little dead weight. Either is a good strategy.
Having a "Lib" folder at the same level as source projects is a common way.
To be honest, it's not the dependencies my projects have that I find hard to manage, it's the dependencies the dependencies have. I'd just like to mention NHibernate, Castle Windsor and the various Castle Windsor Facilities in particular. Getting all of those to play together on my last project cost me a lot of time.
For open source projects, I also like to have the source code handy because sometimes its useful to debug into the source code. (And sometimes because the documentation is so poor, you have to read the source code to find out how it works). I've seen VS projects arranged so that the project references the DLL yet at the same time, VS knows where to find the source code, as I write I can't quite remember how to do that.
So, a Lib folder for DLLs works for me; I often call it "Shared Dependencies".
As for open-source source code, I don't have a standard way to version that because each project is structured differently and has a different build process. I don't like to tinker with the open-source project structure or build method because then, I take responsibility for it. If for some reason, it won't build, or builds incorrectly, or produces a faulty DLL, the cause would be exceedingly difficult to track down, and I'd have to get deep into troubleshooting all of that which I dont care about at all.
In a folder UNDER your solution directory, e.g. "external" or "library". That way your continuous integration system (or other team members) can do a pull of one root from your source control system and have everything they need.
In SVN, use svn:externals to pull that directory from a different root so you can easily share library DLLS (and library projects) between solutions.
In the office we have a share on the network for referenced asseblies. These could be 3rd party or assemblies of our own that could be shared between projects.
I also, don't like the idea of putting the dll files in source control. If all the developers have access to the share all will work fine.
The visual studio directory in My Documents seems like a logical place to put them. I don't know if it's the best or anything wrong with it but at least all the libraries are found in one place.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
At my company we place all our shared DLL assemblies onto a network drive in a folder called Assemblies. From there, we use SyncToy to mirror changes between that folder and a folder on our local development machines (in my case C:\Assemblies with subfolders for different versions or useful third party assemblies). Using the "Reference Paths" feature of Visual Studio projects makes it very easy to select different assembly versions based only on locations.
For projects at home, I would definitely go with the idea mentioned by Jeff M of placing them in the Visual Studio folder under My Documents.
I don't have a hard and fast rule on the location. However, I would encourage consistency!
For example, I needed to to this for a small tool I'm writing for a client at the moment, so I checked their other code bases in Bitbucket which seemed to use a dependencies folder in the solution folder (alongside the other projects), so I copied that.