This question is a followup to an earlier question and subsequent questions raised by research on MSDN per the links provided in the answer.
Here's an image of the solution explorer I've set up so far & I want to make sure I'm on the right track organizationally.
First, because VS2010 is for a C# Class I'm taking, I'm organizing a ProgrammingClass solution (ITDEV110) and Assignment projects (ASSN3a, ASSN3b) within that solution. I read somewhere that a solution is like a house and a project like a room...so this makes good organizational sense to me.
Given that organizational strategy, I can't find the best way to save a copy of Assignment1 as the basis of Assignment2. Sometimes I get proj2's *csproj file in the proj2 path, but the *cs files in the proj1 path. Other times, my *cs files show up in solution explorer as a dotted outline icon (not the *._cs in the pic). I can still click, edit and save, but they still look like ghost classes in explorer--and I'm not sure what that dotted ghost line means to the compile and run.
So how can I move *cs files between projects in a single solution without
confusing VS2010 into thinking it has two Mains, and
ensuring the right versions of classes and methods are called?
Is it just a matter of "Save As..." a new project name? Or should I create a new project from existing code? Is this a job for namespaces? How does this differ if I want SOME of the code from #1 to BE accessible from #2?
I've been doing a lot of creating new classes for my programs by cutting-pasting from notepad...but I know there's got to be a better way.
Any resources or tips would be awesome.
Create a new different C# project for each programming assignment you get. Feel free to use the same Solution, but it's best to keep projects separate. It is possible to share files between projects (using Linked files), or references types and classes from other projects using Project References, but putting school work code into the same C# project is a lesson in pain.
Related
I am pretty new to C# but I have worked a little bit for my classes. When I worked in C#for classes, our teacher used to tell us the namespaces that we needed for completing the assignment.
I wanted to know where do I find all the collection of the namespace for C#.
One of my friends directed me to this site
https://learn.microsoft.com/en-us/dotnet/api/index?view=netframework-4.0
but some of the namespaces did not work for example,
enter image description here
I am working on a small project with ASP.NET MVC and wanted to try different namespaces
I think you may be a little confused, or are possibly not asking the question correctly. The link you provided does contain a list of the different libraries (namespaces) available in the C# API.
If you try to use a namespace in your own code, and it does not resolve, you may need to add an assembly reference to bring that namespace into your project. VS usually does a pretty decent job of guessing what assembly, or missing using statement is required if you either press alt+enter, or click the context drop down under the missing library (denoted by the red squiggly).
Either way, you should just start coding your MVC project, and then google the issues you come up with directly. Asking for all the namespaces is very very vague.
I'm a Unity developer and just made the jump from Monodevelop to Visual Studio Community. Overall Visual Studio Community is a huge improvement but there is one thing I miss that Monodevelop did better: With Monodevelop's auto-completion, it would always sort the functions / variables by class. With VSC, it just shows every possible conclusion in alphabetical order, including all class and base class methods and properties.
So, in the example shown here, if I start by typing "PauseManager." in Monodevelop, it will show autocomplete suggestions first for PauseManager, and then below that for it's base class System.Object.
However when I type the same thing in Visual Studio, it will show me a huge list of methods and properties in alphabetical order, the majority of which I'm unlikely to be using.
This is a very simple example of a small class with only one ancestor; you can imagine that this gets especially unwieldy when I've got a class with a dozen public methods and multiple ancestors, each of which have their own public methods and properties.
I've looked at the documentation for Intellisense here: https://code.visualstudio.com/docs/editor/intellisense and I don't see any options for what I'm trying to accomplish.
Does anyone know of a way that this can be done? If not I may have to reluctantly go back to Monodevelop - looking through all these methods to sort out the ones relevant to what I'm doing it turning into an annoying little time waster.
Nope, apparently it is not possible currently.
There was an issue/feature request but they closed it 5 months ago with kind of "won't do" as answer.
They linked it to a "duplicate" issue though I honestly don't really see that as a duplicate ...
Maybe you can search for plugins but built-in it seems not possible currently .. what is a pity because now that I know it exists somewhere I also miss it a bit :'D
Go to
Tools -> Get Tools and Features -> Modify
If you have multiple versions, select the proper version.
Scroll down and find Visual Studio Development Extension.
Click the checkbox and hit Modify.
That's all you need to do.
Enjoy✌️
Coming from Java , I'm used to the package structure (com.domain.appname.tier)
Now I've started working on a C# project , where all the projects have depth of 1:
i.e
ProjectA
- Utilities.cs
- Validation.cs
- ....
- Extraction.cs
and all the cs files are around 2,500 lines long ...
How do you order your classes and namespaces in C# so it will make sense , and keep the source file in logical size ?
The same way as I'd imagine you do in Java:
A few (< 10?) classes in each namespace, with namespaces arranged in a hierarchy
One class per source file
One or two screenfuls of text per source file
The project you've joined doesn't sound very structured and isn't a good example of good source code organisation.
In a similar way in Java, you just need to make some effort :) Some C# developers, especially with VB background, tend to write looooong classes and put them at the top level.
I would suggest reading Microsoft guidelines on the subject:
Design Guidelines for Developing Class Libraries
In particular you should look at the following section:
Guidelines for Names
Even if you are not writing a class library you may still benefit a lot from these guidelines. FxCop (or Code Analysis as it is named now) will flag many constructs that are not in accordance with these guidelines.
I would first start grouping the classes together into areas of functionality, areas around authorisation for example would go under a folder within a project.
Then update the namespaces of the classes in the folder to reflect the change, Resharper does this for you and newer versions of VS will probably do too.
Lastly (if you are able) I would start to break the classes to smaller more manageable size.
Here's an example of how I organize my solutions, which mirrors the namespace structure.
The project has a default namespace which, in this case, is CompanyName.ProjectName
Source files are organized logically into a directory structure. In the example, my WF4 activity designers are organized under Activities in a folder called Designers.
The way VS works is that, as you create directories in a project, you are also creating namespaces. So, if I were to add a new activity designer called "Foo" in the shown directory, its namespace would be
"CompanyName.ProjectName.Activities.Designers"
Visual studio takes the default namespace, then uses the folder structure to determine the namespace for a particular file. Of course, once the file is created, and you move a file, it isn't automatically refactored. But the system works very well for not only controlling namespaces for classes, but also for keeping files organized.
The same way as you would in Java.
In Java, packages organize classes in physical directories. I'm not sure about this, but the compiler even encourages this convention IIRC. In C# you're not obliged to organize your classes into separate directories that match your namespaces, but it's a very common convention though.
Speaking of namespaces in C#, they do not follow the com.domain.appname.tier convention, but use the Company.Product.Tier format.
How to reorganize large classes depends on the application. This is an exercise in applying OOP guidelines and applies to both Java and C#.
if you are deeply engaged in the project ,i recommend investing some time in redesinging the stucture the way you used to in java ,considering that packages are equivalent to namespaces in c#.
A C# programmer rewrote a Delphi 6 program (no GUI, just files-in-files-out grinding, about 50 procedures and functions totaling less than 1200 lines == 57kb keystrokes) that lives as a single .DPR file.
He delivered a project containing 58 files (52 of them .CS files) in 13 folders nested to various degrees, totaling over 330kb.
Is that typical of C# projects? What strategy do C# programmers typically use to decide how to chop up and organize their project?
Code-file size is a horrible metric to determine the worth of a project, especially in line-of-business projects. Three reasons for that:
1) Small code files are easier to understand than large ones, but this can lead to some repetition of certain constructs (using declarations, namespace declaration, etc.) and certainly adds to the number of files in the project.
2) Small classes are easier to understand than large ones. This is a major benefit for newcomers to the code. If they can wrap their head around any one class, they can expand their understanding outward from there.
3) Good code is larger than small code. When you add decent error-checking, documentation and descriptive method/variable names, your code is more resilient and maintainable, but also much larger. That's perfectly okay.
Now with that all said, of course there are plenty of cases where the code is big simply because the programmer doesn't know what they're doing. You'll be able to identify that by looking at the largest files; if you see a lot of repetition of precisely the same code... or if you see lots and lots of string concatenation.... or you don't see any comments at all (or the comments don't tell you anything useful) then you probably have some good old-fashioned code bloat on your hands.
It's more an artifact of the developer using Visual Studio IDE (VS) rather than an issue of C#/.NET itself. The tendancy, when using VS tools, is to put each class in its own .cs file because the Solution Explorer window shows files/folders in a tree-like structure allowing the programmer to visually target their classes quickly.
Also the Visual Studio Add New Item dialog encourages a one-class-per-file approach by generating a new file each time you add a Class to your project.
The namespace hierarchy of a program is usually mimicked using directory folders in Solution Explorer (although it's not required to match) but this is just another visual quickie.
Example:
(source: spaanjaars.com)
If the programmer were to work outside of the Visual Studio environment you'd likely have much less diarrhea on your hands. Ewww...
Without seeing the actual code of the original or the new code I can't tell you if the new organization is properly designed code just by knowing the line count, method count, and file size. In C# I usually :
Separate each class and interface into its own files.
Static helper methods are grouped by function
I usually separate files into folders by layers. Ex. GUI layer, Business Logic Layer, etc...
Extension methods are separated by the class or interface they relate to or sometimes by function.
Now, the new code could be broken up to follow a more object oriented design, but I can't tell without seeing the code.
Delphi is a great language, but its not a magical language. So no, what you are seeing is not a typical scenario.
Without knowing anything about what your program does its hard to impossible to make any meaningful comment about why your programmer decided to a) rewrite it and b) why the disparity when he did.
I will say this though, its common that when developers do not understand someone else's source, and especially when they do understand the requirements they will choose to rewrite rather than refactor. It's something we see in this industry time and time again.
I have been working for quite sometime to transfer all of the installations for my job from Wise for Windows Installer to WiX. Started with the obvious step (given the number of installations to transfer and their size) and decompiled them with Dark.exe (WiX toolkit). I have been creating a general purpose program to clean up the output from dark into a proper project that we can then compile into MSI's. The problem that has been kicking my #$$ for some time now is the merge modules. We have a maximum of 20 Microsoft MSM's in the various installations, and dark doesn't recongnize these as such so instead lists all the contents. I have everything in place so I can erase this garbage code and replace it with the proper Merge tag. Hence the problem. The merge modules don't have any rhyme or reason to where they are placed, no logic I can find to look for the main folder. The only real common ground is that the Directories, Components, Files, and Registry tags all have an Id ending with a GUID. Any ideas would be greatly appreciated. I already have the frame work in place to search through our list of Merge Modules and retreive the list of files, components, and directories. I just don't know what to look for so it is not speciallized to just one or two modules, but in theory all MICROSOFT modules (I know other companies might use other formats, but that is a mute issue). Thanks again!
It looks like you have been doing a lot of work reverse engineering the existing MSI's and cleaning up the result in an automated or semi-automated way.
Wouldn't it be more efficient and less error-prone to just create the wix source files from scratch? You might be able to leverage the heat.exe tool to reduce the required effort.