We are developing two versions of an application. Not in the sense of a lite vs standard version of the application, where one version will have limited functionality etc. We will actually be displaying different types of information in the application, depending on the version (that's the best way I can describe it without going into too many details).
To differentiate the two versions of the application we've considered using the conditional attribute and the #if directive (if there are any other options or better way than these two, I'm open for suggestions). After some research and debate, we've decided to go with the #if approach, since this will not include the unnecessary code during the compile process (whereas the conditional attribute will just remove the calls to the methods that do not meet the condition, but still include the methods... if I'm not mistaken). I realize the two are not mutually exclusive, so we could always mix and match if need be.
Anyway... What we're now wondering, is if there is a way to only include certain windows forms during a compile, based on which version of the application we are compiling. We have split out all of the logic, so the forms are really just forms, with very little code inside them (mostly just calls to form manager classes that handle all of the business logic). The form manager classes will contain some of the #if statements inside of them, so the code can be reused in both versions of the application, whenever possible (instead of making two classes and putting a conditional attribute on the classes... though maybe this is something we should consider).
Is anyone aware of a good way to do this?
TIA
UPDATE:
Just an FYI of what we actually decided to do. We put the different versions of the forms into separate namespaces and then only had to use an #if statement around the namespace using statement at the top of the class that manages all of the forms. Worked out pretty slick and was very litte work.
I do this with library projects. I produce another project (.csproj), and then include into that project the existing sources. In VS2008, right click on the new project, Click add Existing Item... and then instead of clicking Add, use the select arrow to select "Add as Link".
Rather than duplicating source modules, Add as Link will include a reference to the existing source, into the new project. This way you can have N projects, each with a different combination of source modules. I use this in concert with #if statements within the source of common modules to produce different versions of a library.
Add Existing Item http://www.freeimagehosting.net/uploads/th.eff09391e9.png
full image
Add as Link http://www.freeimagehosting.net/uploads/th.f12b764887.png
full image
Another way to do this is using OO inheritance: put functionality that's common to both versions in a superclass, and then create separate subclasses which define the specializations of the superclass for each of your versions.
You can then build your superclass[es] as a shared library, and build each specialized subclass in separate assemblies (which reference the common shared library).
Doing this uses no conditional compilation nor conditional build options.
The solution suggested by ChrisW is probably the correct way to do it. However, it may involve a lot of changes to your design, so here is another one : instead of having several configurations for the same project, create another project with the same sources. To do that, the easiest way is to create a copy of your .csproj file and include it in the solution
Related
I have a solution with multiple projects each of which connects to the same DB and uses overlapping constant values that I would like to set somewhere instead of replicating manually. I have tried a variety of things online like making a custom class and linking projects to it, setting constants in a project config file (which doesn't exist like the guides claim), and so on. I've been unable to figure this out after more than an hour of searching and experimenting so if you have any ideas, let me know. The structure looks like this (the blue-underlined stuff are some of the projects in the list):
You can make another project under the solution to contain your class.
All the other projects can then reference that project, meaning the same functionality will be available in all the other projects without having to duplicate anything.
I will extend the previous correct answer with some more information.
Your solution structure is something to think very carefully as it is a combination of application design/architecture and leads to extensibillity, scalability and future maintainability.
Take for example the following article Common web application architectures.
You can see the Clean Architecture (AKA Hexagonal) which leads to specific projects withing a solution
You can see older designs where the DB access would go into a project called ..DAL
Simple projects can use the second one, more business rich ones the first or something in between.
Check this this article on shared code projects to see about net standard projects
So the above was helpful, but far more complicated than it needed to be. Apparently other answers I'd seen actually work, but it took reading a bunch of other pages to figure out the whole puzzle. The working steps are:
Create a class with public parameters for your constants
Place that class somewhere in your solution space. When I created it on the solution, it was placed in "Solution Items" in my tree (which is the root folder of the solution on the file system).
Right click each project and ADD>Existing Item and point to the class. The KEY (that was missing from most things I read) was that the "add" button" has a drop-down arrow that lets you change it to "Add as link"
In each project (after adding as link to the file), you can directly reference the values as NAMEOFCLASS.NAMEOFCONST but ONLY if you declared them as public const SOMETYPE SOMENAME. Without the const, it's not able to directly reference the value
Note that this fix is in the .sln file itself and needs to be part of the commit or it won't have any effect. It would be nice if you could use "include" or something to bring in a file a folder one level up, but here we are.
My C# .NET solution files are a mess and I am trying to find a way of getting things in order.
I tried to put all close files together in the same folder I am creating for that purpose. For example, I put interfaces, abstract classes, and all their inherited classes at the same folder. By the way - when I do that, I need to write a "using" statement pointing to that folder so I can use those classes in other files (also a mess I guess).
Is there an elegant way of doing things more clean, and not a list of files that I find very confusing?
Is it a good idea to (let's say) open a abstract class file and add nested classes for all the classes derived from it?
Is there a way of telling the solution to automatically set the folder "using" statements above every class I create?
The best way is when your solution file system structure reflects your program architecture and not your code architecture.
For example: if you define an abstract class and after have entities that implement it: put them into the same "basket" (solution folder) if they make a part of the same software architectual unit.
In this case one by looking on your solution tree can see what is your architecture about (more or less) from very top view.
There are different ways to enforce the architecture vision, understanding and felling of the code file system. For example if you use some known frameworks, like NHibernate, or (say) ASP.NET MVC tend to call the things in the name the technolgy calls them, in this way one who is familiar with that technology can easily find itself in your architecture.
For example WPF force you define in code things in some way, but also you need to define byb the way Model, ModelView, View.. which you will do intuitively in seprate files. The technology enforcce you to define your file system in way it was thought.
By the way the topic you're asking for, is broad known dilema/question, not resolved, cuase the code is just characters sequence and nothing else.
Good luck.
It sounds like you're hitting the point where you actually need to break things up a bit, but you're resisting this because more files seems like more complexity. That's true to a point. But there's also a point where files just become big and unmanageable, which is where you might end up if you try to do nested classes.
Keeping code in different namespaces is actually a good thing--that's the "issue" you're running into with the folders and having to add using statements at the top of your files. Namespacing allows you to logically divide your code, and even occasionally reuse a class name, without stepping on other parts of your code base.
What version of Visual Studio are you using? One little known feature of Visual Studio is that it can automatically create the using directive when you type a class name. That would eliminate one pain point.
If I was in your shoes, I'd start looking for logical places to segment my code into different projects. You can definitely go overboard here as well, but it's pretty common to have:
A "core" project that contains your business logic and business objects.
UI projects for the different user interfaces you build, such as a website or Windows Forms app.
A datalayer project that handles all interactions with the database. Your business logic talks to the datalayer instead of directly to the database, which makes it easier to make changes to your database setup down the road.
As your code base grows, a tool like ReSharper starts to become really important. I work on a code base that has ~1 million lines and 10 or so projects in the solution, and I couldn't live without ReSharper's go-to-file navigation feature. It lets you hit a keyboard shortcut and start typing a file name and just jump to it when it finds a match. It's sort of like using Google to find information instead of trying to bookmark every interesting link you come across. Once I made this mental shift, navigating through the code base became so much easier.
Try using multiple projects in the same solution to bring order. Seperate projects for web, entity, data access, setup, testing, etc.
IF the files are in the same namespace you won't need a using statement. If you're breaking your code into multiple projects you'll need to reference the other projects with using statements.
Its up to you. Break things apart logically. Use subfolders where you deem necessary.
Not sure.
Yes, but you'll need to create a template. Search for tuturorials on that.
1) Your solution folders should match your namespace structure. Visual Studio is set up to work this way and will automatically create a matching namespace. Yes, this requires a using for stuff in the folders but that's what it's for.
So yes, group common stuff together under an appropriate namespace.
2) Yes, subclasses should probably live in the same namespace/folder as their abstract base, or a sub folder of it. I'm not sure if you mean all in the same file? If so I would say generally not unless they're very very simple. Different files, same folder.
3) Not that I'm aware of. If you right click the classname when you use it you can get Studio to automatically resolve it and add a using (Ctrl + . also does this)
I'm writing a library that has a bunch of classes in it which are intended to be used by multiple frontends (some frontends share the same classes). For each frontend, I am keeping a hand edited list of which classes (of a particular namespace) it uses. If the frontend tries to use a class that is not in this list, there will be runtime errors. My goal is to move these errors to compile time.
If any of you are curious, these are 'mapped' nhibernate classes. I'm trying to restrict which frontend can use what so that there is less spin up time, and just for my own sanity. There's going to be hundreds of these things eventually, and it will be really nice if there's a list somewhere that tells me which frontends use what that I'm forced to maintain. I can't seem to get away with making subclasses to be used by each frontend and I can't use any wrapper classes... just take that as a given please!
Ideally, I want visual studio to underline red the offending classes if someone dares to try and use them, with a nice custom error in the errors window. I also want them GONE from the intellisense windows. Is it possible to customize a project to do these things?
I'm also open to using a pre-build program to analyze the code for these sorts of things, although this would not be as nice. Does anyone know of tools that do this?
Thanks
Isaac
Let's say that you have a set of classes F. You want these classes to be visible only to a certain assembly A. Then you segregate these classes in F into a separate assembly and mark them as internal and set the InternalsVisibleTo on that assembly to true for this certain assembly A.
If you try to use these classes from any assembly A' that is not marked as InternalsVisibleTo from the assembly containing F, then you will get a compile-time error if you try to use any class from F in A'.
I also want them GONE from the intellisense windows. Is it possible to customize a project to do these things?
That happens with the solution I presented above as well. They are internal to the assembly containing F and not visible from any assembly A' not marked as InternalsVisibleTo in the assembly containing F.
However, I generally find that InternalsVisibleTo is a code smell (not always, just often).
You should club your classes into separate dlls / projects and only provide access to those dlls to front end projects that are 'appropriate' for it. This should be simple if your front-end and the group of classes it may use are logically related.
If not then I would say some thing smells fishy - probably your class design / approach needs a revisit.
I think you'll want to take a look at the ObsoleteAttribute: http://msdn.microsoft.com/en-us/library/system.obsoleteattribute%28v=VS.100%29.aspx
I believe you can set IsError to true and it will issue an error on build time.
(not positive though)
As for the intellisense you can use EditorBrowseableAttribute: http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx Or at least that is what seems to get decorated when I add a service reference and cannot see the members.
I am working on a project in which my entire team is facing the following problem, please help me to discover the issues associated with the approach which we have decided to follow so that we can save ourselves beforehand :)
We have decided to separate out the entire code of our application into just three projects in a single solution.
1) One project will contain entire UI
2) Second will contain entire business logic. In this project the code corresponding to different modules of our application will be separated via different namespaces rahter than having separate project for each modules or dependent modules.
3) The third project will contain all the common code
I am still able to see that there might be some problem in future if we put the entire code in second project under different namespaces in a single dll rather that splitting it in different dlls/projects.
We are working on a WPF based application.
Please help!
Shahil Gautam
I am still able to see that there might be some problem in future if we put the entire code in second project under different namespaces in a single dll rather that splitting it in different dlls/projects. We are working on a WPF based application.
The only "problem" with doing this is that it's a bit easier to "accidentally" reference types in other namespaces. If you separate into separate projects, the only way to "pollute" your type with business logic unrelated to it would be to explicitly add a reference. When it's in the same project, you can have a using statement or a fully qualified type name, and "use" an unrelated type without any compiler warnings.
I think that's a sensible choice. I general, assemblies should be units of deployment. There is no need to have 10 assemblies if they are always going to be deployed together.
One issue however is that you will have to be more careful about your dependencies within a project. When separating things into different projects, there are physical barriers for introducing inappropriate dependencies, while now you will have to be more conscious about this. A tool like ndepend might help you find suspicious dependencies in your code.
I do not see why you would want to have multiple namespaces within your business logic project.
There are two possibilities:
ONE. All of the types that you define in the project have different unqualified names.
In this case, separating the namespaces would have little purpose. The only benifit would be that the intellisense object selections would be shorter and clearer when the usings to the other namespaces are omitted. Putting the types into separate projects would accomplish the same thing just as well, and offer better separation of concerns.
TWO. Some of the types in the different namespaces have the same unqualified names.
In this case, confusion could easily result, whenever a using from another namespace is added in an unsuccessful attempt to reference a type from another namespace with its unqualified name. If there is no danger of that happening, then, once again, why not put the objects into separate projects, since, clearly, the lines between the domains are sharply drawn?
How should I divide source files into projects (within one solution) to
be able to use common classes in more relatively independent apps,
avoid lots of dlls needed (preferably all in one file for each application),
keep it fast?
There are working (data processing) classes, User controls, some utility classes and Forms of the application.
You can make a separate assembly by creating a class library, and use that library within other projects within your solution. Just put your reusable classes within a class library project, and add a project reference in your applications to that library.
Each time you separate out code into a separate (reusable) assembly, it does add one extra DLL (the class library project) as a requirement at runtime, but this is very minimal.
There are no real (significant) changes to performance when doing this. It is a very common practice.
You should make Class Library project(s) for each logical unit of classes, then add references to the libraries in each project that uses them.
For example, you could have a Common library that contains basic classes used by everything else, and perhaps a Controls library that contains user controls.
Each logical unit of classes can go in a namespace within the same library or in a separate library; you need to decide which.
It would be a good idea to drop the second requirement of avoiding lots of DLL's. If you put your common code into a single "common" DLL then you need to recompile every time any class is added or modified. This could then give you a terrible versioning problem that is worse than managing lots of DLL's.
You should group your common code, by the functionality they provide, into separate DLL's. So one for data access, one for user controls, one for each type of utility function, etc. Then if you have web service that accesses data you won't need to recompile the service when you add a new user control to a single DLL. Only those apps that depend on the change will need to be recompiled.
You could put the common classes into one assembly (say CommonUtils) and then use namespaces inside for the groupings to indicate how they are split