Develop Reference

How do I build code out of a tutorial repo that has many examples (in Visual Studio/C#)

How do I build sample code, split into folders in a repo, from a class or tutorial, in Visual Studio?
So - I'm pretty much a noob at C#, I've gone through a lot of tutorials and browsed through some large C# projects from work and built them, and done some other minor things. I'm going through a course on writing testable code on Pluralsight. He has a public Github repo for the code examples, writing-testable-code. I connected to the repo and downloaded it okay into a local Git repo. I was able to download all the packages from NuGet and they are all showing as the version he used (a few have updates, but I figured updating might break things).
I can't figure out how to run this code, build it, or run the tests in it.
What I tried so far
My issue is - I open the solution, and there are a bunch of files and folders - each module/chapter is split into folders (i.e. Module1/Easy, Module1/Hard, Module2/Easy, etc.). I want to build the Module1/Easy folder, including unit test examples, and run the tests.
When reviewing Module1/Easy, it has 3 files that should build okay - the program.cs has a main() and looks like a console app, the Calculator.cs has a simple class, and the CalculatorTests.cs has unit tests built for Nunit. The solution has NUnit, Castle.core, and things from later modules (Moq, AutoMoq, Unity, Ninject, etc.). It didn't seem to have a VS runner, so I added Nunit3TestAdapter - the guy in the course has resharper installed, which I don't, and he was using the Resharper test runner, which would explain why he didn't include it.
I tried setting the "Module1/Easy/Project.cs" file the "Set as Startup Item", since it has a main and looks setup as a console app. However, running it (the "Start" button turned into a "Program.cs" button), it fails saying it can't run a dll. The tests aren't showing up in the Test Explorer like some other small projects I've built from examples.
What's the right way to do this?
I'm not sure where to go from here. On the Build menu is only a "Build Solution" and one about Code Analysis - I'm used to a lot more options here. It feels like I have to turn this folder into a project, maybe? I can always reinstall the packages - but what is the best solution here?
I've run into this before on other book, tutorial, or class repos, but finally decided to figure out how to get this one working. I appreciate any help!
Notes
I'm running Visual Studio Community 2017 at the moment.
I can post some of the files, but the repo is publically available, and not sure exactly what to post to help.
Progress from comments and answers
Per Biker-Dude's answer, I switched the project to build a console app rather than a dll, and now I get a compile-time error for having multiple entry points (i.e. every module and sub folder has its own Main() function and should probably be a separate project).
After #1, I removed all folders but one from the solution, it will then compile, run the tests, etc. - but I eventually want to be able to at least separately compile every sub-folder - what's the best way?

The problem must be that the project must have the output type set to class libraries. Browse through the solution tree and:
Select your class's project> right click > Properties > Application >
Output Type > Console Application/ Windows Application.
This should fix it, if the other things are set up properly.

With the help of BikerDude's answer and stijn's comments, I was eventually able to play around with this and get some things working.
First of all, don't try to exclude any folders in this situation, that will just make things worse! They will still be in your underlying folder/repo, just won't be showing up in your solution anywhere, and you won't be able to create a new folder with the same name (weird decision...). And you'll have to add them back in as individual files - I think.
The best solution (so far)
The best solution seems to be:
Create a new project for each buildable set of files in the solution (in my case, at least one project per "module" folder). I used the ".Net framework console app" project type (right click on the solution, use Add/New Project) to get things to work, but this would depend on the particular course or tutorial repo you downloaded.
Move the folder or sub-folder that has the files you want to build out of the main solution and into the new project - you can click and drag to move it.
Visual Studio will make an empty, pre-formatted file in your project that you likely have to delete - for .Net apps, this is the "Program.cs" file in C#. For one of my folders this file already existed, and I had to delete the new one in order to build. Another folder from a different module was setup more like a library and couldn't build standalone, but this procedure did get me to being able to build the files and that allowed the unit tests to show up in the test explorer and run the tests successfully (which was the main point of that module).
Go to the solution and right-click and choose "Manage Nuget Packages for Solution". As long as all the packages are installed for the main solution, then they will all show up in the list of Installed Packages (you might need to click on the "Installed" tab). You can click on each package in turn, then on the right you can checkmark the new project, and the "Install" button should be available - click it. Repeat for all the packages to install them all. Note that you can cut out some repetition here if you create all the projects you need first, then you can install all of them at the same time in this step (i.e. checkmark all the new projects at once instead of reopening the package manager each time).
You might have to fix the NameSpace - it should be consistent within the files/folders you transferred from the original solution, but if you add any new files to play with things, the Namespace for it will likely not match, and to see classes, etc. in the original files, you'll have to update your Namespace on the new files.
Per BikerDude's answer - After transferring everything to new projects, if you keep anything in the original project that came with the solution, it might not be trying to build the right type of item. You may be able to fix that by right-clicking the project, selecting properties, and adjusting the "output type", but it may not have the options you need. If it doesn't, just create a new project with the right type and transfer the files as above.
After following the above steps, I was able to build each new project I created, using the original files from folders that I moved. Mainly I just needed to build, which enabled all the unit tests that this tutorial/class was focused on, but this allowed me to build the console apps as well, when present.
Thanks for the help from all in pointing me in the right direction!

Build same Project as Console and DLL

I've got an C# Project in Visual Studio, which has Console Application as Output Type.
But I also need a Class Library of this project for another solution.
Right now I have to switch the output type every time, but I wonder if it's possible to generate exe and dll at the same build-event?
Is there a post-build-event for this?

To my knowledge there is no possibility to change the output type after compilation. That being said, if would be possible to have two projects like Console and Library in your solution, which would use the same source code files but have different output types. That way you would have different outputs without any duplication of code.

it is generally possible to reference a .net exe assembly as it would be a class-library.
So you can just stick in creating an exe file and reference the exe (sounds strange, but works) in your other project.
This is the dialog for browsing for references. As you see you can select exe files.
But as commented it really depends on what your usecase is.
I don't recommend to ship an exe with an entry point to your customer hoping that the customer does not discover the exe. But what you could do about that is to conditionaly compile your entry point.
For example
class Program {
// This is the entry point of the EXE
public static void Main() {
#if DEBUG
// Start Debug Application
...
#else
// Shipped to client - Entry point disabled
return;
#endif
}
}
If there is a relevant reason to have a shipped exe and a shipped class library, I would refactor your solution like this:
(A) complete application (.sln)
(B) console-application (.csproj) which has a reference to (C)
(C) class library project (.csproj)
With that it is perfectly clear to others that there is an application that uses the library and the library itself.

Console Application is the type of your project. You can not change it.
What you can -and must- do is, carry your logic into a Class Library project and use your class library from any type of project you want.

You should compile your project to become a dll and then use this dll in a console application.
A possibility to achieve what you want is to manually run the msbuild on your post-build event of your project.
See: How do i build a solution programatically in C#?
or Building C# Solution in Release mode using MsBuild.exe

The usual solution for this is using a Solution with two projects:
a Class Library with all the code (which builds into a DLL)
an Console Application referencing the library whose Main just calls some function(s).
For more information, check the MSDN page on Solutions.
Codor suggested manually adding the files to the Console project, but one downside is that build settings are not shared between both versions, so you might get some inconsistency there.

I'm not really sure why people think it's not possible but it actually is.
The easiest way would be renaming the exe to dll Sounds stupid, I know. But it works in many cases. Also, as "Peter I" said a .NET exe can be imported as assembly in other projects. So you might not actually need a dll anyways.
Another way would be using C# command line as stated here: /out (C# Compiler Options)
You can use command command line options in Pre/Post build events Pre-build Event/Post-build Event Command Line Dialog Box

I have a similar requirement and couldn't find any definite answer in this post or anywhere. I currently have a class library and would like to create a console application project without copying any code. Ideally speaking there should be two projects, one for creating a console application and another for creating a class library. And this is what the visual studio also suggests. When I tried to run the class library, I got the below message.
It clearly asks us to add an executable project to the solution and add the reference to the library project.
Below are the steps to do this.
Right click solution -> Add new project -> Console App -> choose name -> ok.
Right click on the console project -> add reference -> In reference manager, click on the projects tab and select the other project(In my case this is the class library project, In case it is not listed just click on browse and select the .csproj file) -> ok.
Now to use the classes in the other project, simple do using LibraryProjectNameSpace
There we are. Bingo!!!!
Also as mentioned in the other answers it is not possible to have the same project generate both .exe and .dll. But you can have the same solution generate these two guys by having two projects. In this way there is no need to switch the output of the project every time.
FYI, I use visual studio 2017

Changing source code in a class library seems to have no effect on application

I was given a project in which I am supposed to debug a problem in a Windows Forms application. I found where the problem is located but it is within a Class Library which is included as a component of my Windows Forms application solution.
How can I add/modify code in the Class Library project and actually run it live so that I can debug it? If I make any changes to the Class Library as is, the application ignores the changes and resorts to the original source code.
The only things contained in the Class Library's folder are plain source code files, some settings files, and a .vbproj. I just want to make changes to the Class Library and actually be able to debug them. If anyone could please explain what I have to do, it would be greatly appreciated!

Your application is not loading the assembly produced by compiling the class library. It is loading another copy from somewhere.
One quick way to find out where is to start the application from Visual Studio, break into the debugger and then bring up the Modules windows (Debug>Windows>Modules). Look for the class library in the Name column and check the Path.
If it is under C:\Windows\Microsoft.NET\assembly... then there is an older version being loading from the GAC. If it's another location, you will need to ensure the class library project output is going to that location.
Does the startup project have a project reference to the class library in the solution? You could always remove and re-add the reference to the class library in the startup application project and ensure you add it as a project reference.
Be careful though, there may be a good reason why this wasn't the case originally.
EDIT
A full explanation of how assemblies are located is way beyond the scope of an SO post - you'll need to study How the Runtime Locates Assemblies.
With no changes made to typical solution defaults, a library is most likely to be loaded from the same folder where the start-up executable is located. Setting a project reference to a library causes it to be compiled and copied to that project's bin folder - so make sure the startup project has a project reference to your class library project. (Right-click startup project and check Add References... dialog. The reference should come from the Solution section).
You'll need to examine the project property pages to see if something special has been configured.
99.99% of the time, building the WHOLE solution and hitting run should work. If it doesn't work, something is messed up in the solution and/or there is some kind of custom deployment set up.
There are simply so many ways to deviate from the default deployment that I just can't give specific guidance here; you best bet is to get someone knowledgeable who can take a look in person, or to whom you can send the source for inspection.

I just went to Project Properties ....Project Dependencies and checked(ticked ) the class /assembly(.dll) name... It worked for me. Now i dont need to run the class project for the changes to reflect in the Startup Project ..

Good practice for working with multiple solutions in Visual C# Express

Background: My team is made up of 3 fairly inexperienced developers. We are developing in-house software for our company. Currently we have a number of smaller and separate solutions. Many of these are interdependent. Currently these depencies are made by referencing the output dll's in the respective release-folder. Updates are pushed around by manually rebuilding dependent solutions.
Example:
Solution A uses features of solution B. The connection is made having Solution A referencing ...\Release\B.dll . Changes to B propagates by building solution B, then building solution A and so forth.
This has worked okay before, but now we are moving from a manual (mind numbing) "version control system" (folder1, folder2, folder2New...) to using a proper one (git).
It seems that versioning the .dll's is not recommended. This means that every time someone wants to build a new version of A, he also needs to build B (and maybe 5 other solutions) in order to have the latest version of B.
I'm thinking that there must be a better way to do this.
I've been looking at combining the relevant solutions into one master solution, but I can't figure out how to do this in Visual C# Express (which we are using).
So at long last the questions:
Is having a master solution that builds everything the way to go?
-- it seems so from MSDN but I can't figure out how to do this in Visual C# Express 2008, which leeds me to
Is this even possible in Visual C# Express? If not, what is a
good way of managing the problem?
Edit Thanks to all for the great suggestions below. Here's a summary of what I ended up doing.
In short the answers to the questions are: "Yes" and "Sort of, but mostly yes". I implemented as follows: In order to get an idea of the dependencies, I did as suggested below, and drew a map of the binary products, with an arrow pointing from the dll's or exe's name to all of its dependencies.
For each project, I opened its corresponding solution (since at first there was one solution pr project). I then added the projectfile of each dependency in the tree structure revealed in the graph (by right-clicking the solution in solution explorer), so that also dependecies's dependencies and so forth were included. Then I removed the old references (pointing directly to the .dlls) and added references to the projects instead.
The important result is:
When a solution of a project is built, all it's dependencies are built with it, so that when deploying, you know that all the build products are automatically of the latest version.

I would create a new solution and add all of the projects that relate to each other to it. You can group the projects from each of the original solutions by putting them in different solution folders within the new solution. This way, when you build a project, all of the projects it depends upon will also get built. It also means that all of your projects will be built using the same configuration (i.e. Release or Debug). This means that all of your projects can be built in Debug, not just the top one in the dependency tree while everything below it is a Release assembly. Makes debugging much easier.

I have Visual C# Express 2010 and when I create a new project, it automatically creates a default solution. If it's visible, then you can right-click on the solution and choose Add>Existing Project.
If the solution is not visible, (I seem to remember this problem in C# Express 2005/8), then you can add an existing project via File>Add>Existing Project. The solution should be visible now.
In terms of speration, what I usually do is this:
Everything that must be built together should be in one solution, and these should be projects and not DLL's. I try to live by The Joel List, where you should be able to build your project in one step. If it is one deployable unit, then there should be one solution. All of my projects are built on a build server before they can be deployed, so everything should be in the solution that needs to be built.
Guys sometimes put the WCF services project and the clients in the same project for easy debugging, but it depends on whether you want to deploy client and server independently. Usually for bigger projects I separate them.
Lastly there's one exception. We have a central common library that is used by different teams. If it's included in different solutions, and one team changes something, we end up breaking the other team's builds. In this case, we create a single solution that has all of the library projects. These get built to DLL's that we store the versions of. We treat these as a framework that the other solutions can use. E.g. Team A is using CommonLibrary 1.1 and Team B is using CommonLibrary 1.2.

You need to think of Solutions as just "groupings of projects" - the projects are what are actually "built", not the "solution" (well, that's not entirely true, the solution is turned into a "metaproject" that references the contained projects, but its close enough to the truth)
If you have interdependencies between solutions, I would suggest drawing all the projects on a big whiteboard, then draw arrows representing the dependencies from project to project. Once you've done this, you'll be able to see at a glance what the appropriate "groupings of projects" make sense. Those become your solution files.
For example, if you have projects A, B, ..., F, where:
A depends on B
B depends on C
D depends on C
E depends on F
One possible split here would be solution 1 with projects A, B, C, D and solution 2 with projects E, F.

I would come up with a common area to push all dlls. My company uses the "R" drive, which is just a LOCAL (not network so no one can touch another persons folder) mapped folder everyone has. Each solution will build to this. Right click a project, properties->build and change the output. Or you can add a post build command to push the dll there. After that, have all of your projects reference this location.
Once this is done and everything is pointing at the same place, you can even add different combinations of projects to different solutions. If a developer only wants the ui projects, they can open a special "ui" solution that is a subset of the whole.
Here is a post build event that I use in my project properties->build events
rem when building on local workstation copy dll to local R:\
if '$(BuildingInsideVisualStudio)' (
xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y
)
rem if "Enterprise" build then copy dll to Corp R:\ drive and to Build Machine R:\
if '$(Reason)' == 'Manual' (
xcopy $(TargetDir)$(TargetName).* \\folder\$(TargetName)\1.0\ /Y
xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y
)

Multiple applications in single solution

I believe this is possible but unsure how to go around it, I need to create a server/client solution, normally I would create a new solution for the server and a new one for the client however I am looking to do this within a single solution as they would both be using the same custom classes and don't really want the issue of having to change the same file twice.
So the question is can I create multiple exe's within a single solution and what are the steps to achieve this.
I have searched on here but don't fully understand the procedure so if someone can point me in the general right direction it would be great. :)
VS2010 using C Sharp and Windows Forms

Please see this and this previous answer which I gave on cross-platform client server application development, specifically with code-reuse across multiple clients. This is also applicable to your Winforms client server app here.
As many answers are saying, you can structure your solution in order to share code as follows:
Project Structure
Solution
.. Common (Messages, Datacontracts, Utilities)
.. Middleware (References Common, provides common services)
.. .. Server Exe (References Common, Middleware)
.. .. Client Exe (References Common, Middleware)
Top level client-server architecture
Your stack becomes
Clients:
Client has serialization, client side implementations of webservices/middleware and Model-View-Presenter patterns for the view.
Middleware:
Middleware, i.e. shared services and data transport implemetation on server / client desktop can be the same. Alternatively you could call this Services. Any specific services for client only (or server only) should go in separate assemblies and referenced only by the specific exe (client or server). i.e. dont share code that isn't shared!
Messages/DataContracts:
Shared across all clients/server using the techniques I outlined above. In your case these may be common domain objects shared between client and server
Server:
All business logic, DB access and server-side service implementations. For DB Access I'd recommend PetaPoco as an excellent MicroORM.
Development and debugging
Yes, a solution can have more than one exe, simply use set Startup Project by right clicking on Server Exe or Client Exe to debug one or the other.
If you wish to run the client and server together, you can run both from the command line and attach the debugger to both processes.
Best regards,

First, ensure you can see the solution file in the solution explorer:
Go to Tools->Options. Then under Projects and Solutions ensure Always Show Solutions is checked.
Then, in the solution explorer (top right, where your project's files are) right click on your solution (just above your project icon) then click Add->New Project.
In terms of the layout of the solution, you'd have 3 projects, the client project, the server project, and a class library project of shared classes.
Your client and server projects would reference the library project, see: Project Reference (MSDN)
See also: Multi-Project Solutions (MSDN)

You would do it like this:
Have one solution
Add three projects to the solution:
Project A: The server exe
Project B: The client exe
Project C: A class library project containing the classes that projects A and B use.
Make project A and B reference project C

You can right click on solution icon located at the top in the solution explorer and choose add new project option.

Add a new Class Library project to your solution. Put your common code in there.
Add as a many WinForms projects you need to your solution.
Add references to the Class Library project to your winforms projects.

There is nothing special about multiple project within a single solution - VS 2010 supports this fully, see http://msdn.microsoft.com/en-us/library/23x5fk78.aspx .

You can also add the same project to multiple solutions. There is no need to have both the server and client output in a single solution.
In other words, if these are the projects you want to use in both server and client:
Project A: CoreClasses
Project B: Entities
Then simply add them to both solutions:
+ Solution 1: Server
+- Project A: CoreClasses
+- Project B: Entities
+- Project C: ServerSpecific -> output
+ Solution 2: Client
+- Project A: CoreClasses
+- Project B: Entities
+- Project D: ClientSpecific -> output
In your trunk, it would look something like:
/trunk/
/trunk/ProjectA/
/trunk/ProjectB/
/trunk/ProjectC/
/trunk/ProjectD/
/trunk/ClientSolution.sln
/trunk/ServerSolution.sln