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.
Related
I have two projects:
ProjectMain (class library)
LibraryProject (class library)
ProjectMain is a class library that should only be compiled as a singular library, no referenced libraries. I require a static class reference from LibraryProject BUT I don't want the LibraryProject assembly to be compiled together with the ProjectMain assembly.
I've tried 'link references' in visual studio but this is no solution as the library assembly is always compiled with the main assembly.
There are clear standard solutions to this issue but I am severely limited by the existing implementation requirements. Only one DLL can be compiled without any of the dependent assemblies being in the execution folder, GAC, private path, reflection etc.
The exact limitations are as follows:
Assembly executed in a sandbox from a third party provider, it only supports adding a single assembly with no direct references/reflection etc (it's horrible but my hands are tied)
We would like to handle the code organisation as best possible which means following standard best practices, unfortunately, due to the above limitation that's proving difficult.
What I would like to know is if there is a way to reference a class within another project without also compiling/using that referenced classes assembly. Possibly a method where the compiler 'embeds' the referenced class at compile time.
If your sandbox does not allow loading other dlls in AppDomain, load it yourself by embedding it. You can use Costura.Fody for this purpose, it is easy to use/install, just reference it from nuget.
Of course, embedding it in every scenario is madness and often comes with completely obscure bugs, which often solvable only by enabling traces in regedit.
So, in your case I would create two projects:
MyDll.csproj //it is my original project, with perfect code design and etc. Lovely.
MyDll.Sandbox.csproj //this one is the same as MyDll.csproj, except it is compiled with additional Costura.Fody reference, into single dll (every reference is put inside)
This way you just need to maintenance that MyDll and MyDll.Sandbox files are the same.
There's one solution which is an upgraded version from VB to .Net. It's a huge project with myriad of library references to third party softwares. The other is built purely on .Net reflection(parallel framework code for concurrency and key certs for scheduled jobs). As a matter of fact there are properties for each of the solutions with dedicated assembly files, settings and resources.
The requirement is to integrate 2nd solution to first one. I managed to transfer stand alone files, without much pain into the main project. But I am not sure what my options are. How to include both assembly files into one project? How to combine the two project properties?
I'll provide my 2 cents
a) How to include both assembly files into one project?
Simply import the 2nd Solutions' Projects into the 1st Solution
b) How to combine the two project properties?
You will need to Refactor them in.
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)
Suppose I have a bunch of namespaces:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Each namespace has its own project and each project creates its own dll file:
SuperNamespace.namespace1.dll
SuperNamespace.namespace2.dll
SuperNamespace.namespace3.dll
SuperNamespace.namespace4.dll
...
SuperNamespace.namespaceN.dll
I like this design because it allows developers to use only the code that they need. Sometimes having a bunch of dll's can be a bit cumbersome and annoying. I would like to create a SuperNamespace.dll which contains all of the namespaces. That way, a developer has the option to use what he/she needs or just take the big dll file, i.e. SuperNamespace.dll containing all libraries:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Is there a way to do this in a C# Visual Studio 2010 solution?
I would simply create one large project with all sources unless there are other reasons to keep separate assemblies.
In later case I'd still create one project that includes everythin in addition to small projects before going ILMerge route as Mith Wheat suggested. You can easily create new project from a lot of files using File->New project from source (may need higher version of Visual Studio for that, defintely not Express ones).
There is no restrictions how many C# namespaces can be used in in one assembly (DLL). You can find many examples in .Net framework itself - i.e. many of System.* namespaces come from the same assembly.
Opposite is true also - same namespace can come from multiple assemblies.
Note that in compiled code there is no such thing as "namespace" - it becomes part of class/struct/enum name.
I have a C# project with two namespaces. A GUI (Stoff3GUI as namespace) with the GUI xaml and .cs files, marked as starting object and a Library (Stoff3Lib as namespace) with all the classes doing the actual work.
Now, when I compile my code, I will receive a .exe file Stoff3GUI.exe and a .dll Stoff3Lib.dll. In Visual Studio, both namespaces are part of the same Project.
How can I compile the classes from the Stoff3Lib into the .exe file without producing a separated .dll file?
Edit:
Changed the xxx to my project name Stoff3 for better understanding.
If both namespaces are part of the same project, you should already only end up getting a single assembly.
This can differ with web project setups (various different flavours of web projects create assemblies in times and manners I've never understood) but for standalone executable projects, it really is "one project produces one assembly" in all cases as far as I'm aware. Double-check that you really only have one project - for example, you shouldn't have any references in the project to an xxxLib assembly.
I'm not entirely sure what you are doing here. It sounds like you might have a single 'Solution' with two projects My immediate thought is just to move the classes you want into the the GUI start project and delete the other project.
I believe what you really have is 1 Visual Studio solution with 2 projects.
Since a picture is worth 1000 words, and just to clear up terminology, here's what that looks like in VS2012:
The output of this solution is exactly what you describe:
TwoProjects\Stoff3GUI\bin\Debug\Stoff3GUI.exe
TwoProjects\Stoff3Lib\bin\Debug\Stoff3Lib.dll
The easiest way to accomplish what you want is to have a single VS project that contains 2 different namespaces. It's good practice to add folders that match your intended namespace structure, in your case Stoff3GUI and Stoff3Lib:
When you compile this solution, the output will be a single EXE, but you still maintain the separation of model and view namespaces very clearly in your folder/file structure:
OneProject\bin\Debug\OneProject.exe