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!

Add referenced projects into solution automatically

My situation:
I have a solution A with hundreds of projects,
Some of projects are class libraries and are referenced from other projects.
Now I want to create a new solution B which will consist of subset of projects of solution A. I start by adding the first pre-existing project into this new solution B. This project is referencing couple of class libraries from solution A. Therefore it is logical that these libraries cannot be found and I cannot build. Of course I could add all the referenced projects manually into the new solution B but that would take quite a long time, considering the total amount of projects that I need to add.
Is there some built in Visual Studio feature that can take care of this on my behalf? I.e. I will be offered an opportunity to import all the referenced projects at once and the B.sln file will be updated automatically.
I also have a ReSharper extension but I couldn't find such feature in there as well.
EDIT:
Some more detail on what I am trying to achieve. A.sln has lots of application projects and literally hundreds of class libraries. I want to create a new B.sln for one particular application project from A.sln and only add the class libraries that it is referencing, directly or indirectly... But the dependencies can go up to 15 levels deep so manually removing projects from original A.sln to create B.sln is really not suitable for me as I would have to carefully consider each one of the projects that I would be manually removing from the original sln file, subsequently reviewing the csproj files to find whether the application I am interested in does not indirectly depends on them via one of its direct references.

Copy paste your current solution file and start with it. Open it in new Visual Studio Instance. Remove your projects one by one. Instead of adding new projects, removing unnecessary ones will be more easy for you. As far as I know there is no such feature in Visual Studio as you want.
Removing will be more easy since projects are already there. Do not use Visual Studio to remove project but open sln file in suitable programmers notepad. Your projects are added to sln file as below lines.
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example.Integration.App1", "..\Example.Integration\Example.Integration.App1\Example.Integration.App1.csproj", "{E3977144-AFBA-451D-894C-1F89AA008041}"
EndProject
Removing such lines will be more easy if your projects has naming convention.

The best way to port references from an existing project that I've found is to generate a template for that project.
On the File menu, click Export Template. The Export Template wizard opens.
Choose project template and move through the wizard
Click Finish. Your project is exported into a .zip file and placed in the specified output location, and, if selected, imported into Visual Studio.
Now, when you setup a new project for solution B. You'll be able to choose the project template from A and all the file structure/references are preserved.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/xkh1wxd8%28v=vs.100%29.aspx

How to extend Visual Studio with TFS to override the Get command

I am working on a conversion from Accurev to TFS and am being blocked by Accurev's usage of symbolic links, which TFS does not work with. I have tried several methods, but they all seem to fail to work.
What I would like to do is have a file in the project/branch that lists all the linked files and folders that is stored in source control. On every get operation, I would like to read this file and link the folders and files specified in the central file. However, I cannot find a way to extend the get operation. Does anyone have any experience in extending it in VS?

TFS does not provide a way to extend what happens on a Get action. You could easily create a custom powershell or batch file that you use in place of calling tf.exe, but since Team Build and Visual Studio call into TFS directly using the Client Object Model you're not going to make this easy on yourself.
In the end everything is possible of course. You could write a custom build action for Team Build to replace the standard get operation, or create one that triggers after the standard get operation has completed. You can write a vsix visual studio extension that replaces the standard Get operation everywhere in the menu's of Visual Studio and get to a something that could be considered workable. But I would not recommend this. It is far from standard and it is far from sustainable. You'll have to unwire so much default behavior in Visual Studio (that checks out files that are changed, adds files to source control when they're added to the project file etc etc etc).
SourceSafe used to have this feature as well (it was called pinning) and Microsoft removed it when they created TFVC. They now recommend you use branching and merging to synchronize these files across multiple projects, making sure that the source structure in Source control is the same as the ones on disk during build.
You can also make use of the Add-as-Link option in your project files. This allows you to keep the original files in their original location, but MsBuild will understand that in the project structure this file actually lives somewhere else. Or package the linked files up in a NuGet package and use the Dependency Management using NuGet guide to help you place the files in the right location during build.
And finally, you can get very creative using Workspace Mappings, many people never get further than mapping $/project -> $(SourceDir), but in essence the workspace mapping is like the file you describe. A way to layout your sources from Source control to disk. You could do:
$/Project/DEV/MyProject -> $(SourceDir)\MyProject
$/Project/Shared/FilesToCopy -> $(SourceDir)\Shared
And you can even add files from other projects in the same collection:
$/AnotherProject/Shared -> $(SourceDir)\MoreShared
And something not many people know, you can layout individual files:
$/AnotherProject/CompanyAssemblyInfoItems.cs -> $(SourceDir)\CompanyAssemblyInfoItems.cs
The only thing you cannot do, is map files to be children of an already mapped folder. In that case you might need to have the workspace mapping do the fetching of the sources and then a .targets file that you include in your .csproj file to do the copying of files.

What is the best way to duplicate a .csproj (for creating the same app with different named exes)?

I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.

In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration

Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)

Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)

I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,

What is the best way to publish multiple versions of the same ClickOnce application?

I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!

I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.

If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.

I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties