Develop Reference

MVC in a Core Library

I built this project and it contained a simple MVC type structure to help with debugging information. Now the company wants to use it in other applications like a Library
The best way, I can describe it is
My Project Debugger Is a single controller with multiple end-points that render views (pretty basic), written in C#.
What I want is when another project wants to include my debugging, they would:
Add Debugger as a reference using NuGet.
Then in Start.cs the developer would use IApplicationBuilder.UseDebugger(IConfiguration, OtherInformation) or IServiceCollection.UseDebugger(IConfiguration, OtherInformation) and Debugger extension would do the rest like registering routes, building what it needs for dependency injection.
What I cannot figure out is what project type to use, I built it using .NET Core Web Application 3.1, but I do not think it is that. I also tried a .Net Standard class Library but I could not get a reference to controller to render views.
So to summarize, I want to convert part of my project to a library to allow for distribution to other applications.
A link to an example project would be helpful as well.

It sounds like you want a Razor Class Library.
Razor views, pages, controllers, page models, Razor components, View components, and data models can be built into a Razor class library (RCL). The RCL can be packaged and reused. Applications can include the RCL and override the views and pages it contains. When a view, partial view, or Razor Page is found in both the web app and the RCL, the Razor markup (.cshtml file) in the web app takes precedence.
Edit: I just realised I answered a question about setting up a Razor Class Library last month, so that will give you a starting point, too.

Is it possible to add C# classes immediately before compilation in Visual Studio

Now I programmatically generate sources and create some classes before compilation and obviously add it to project in solution. Maybe it is possible to "silently" add classes before compilation without creating .cs files in disk and not showing these classes in Solution Explorer (maybe using Roslyn).
EDIT: I must not use any runtime code generation.

You can put the classes in a separate DLL (class library). When you create that DLL using another solution you will not see the classes in your solution explorer of the project where you include them.
Don't forget to add a reference to the DLL (class library) in your main project.

You could probably do something with MSBuild, creating a custom project target which does the work, but I've never done this.
What I have done recently which is now achievable on the DNX-based ASP.NET 5 platform, is a concept known as meta-programming. I've written a blog article about this concept specifically with examples of generating code at compile time. In my particular example, I've got a class that won't compile, but then with an introduction of an ICompileModule, I can fill in the missing method return statement at compile time.
This is possible because in DNX-based applications, the RoslynCompiler class actually supports loading instances of ICompileModule at compile time, and then running these instances before your main project compilation. This enables you to add/remove/replace syntax trees in the compilation before the compiler finishes its work.
If you're looking to develop on ASP.NET 5, this could enable you to do what you need, but I don't know how you would go about doing this otherwise.
Seems quite aspecty to me.
I asked a question which I also answered myself about engineering a compile-time solution that performs code generation for another scenario:
Getting interface implementations in referenced assemblies with Roslyn
And lastly, other examples where this might be useful, and something I've been toying around with, is the ability to generate EF-style migration classes from .sql files embedded in my assemblies. All these scenarios are now easier for me to implement on ASP.NET 5 + Roslyn.

Without knowing your use-case properly, here's an idea...
Create a VSIX that listens to an 'on build' event
Upon initialisation of the build, the VSIX creates your new classes*
The same VSIX will also listen for a 'build complete' event
Upon completion of the build the VSIX would tear down the new classes
*Your question states that the classes should not be created on disc, so the VSIX could
create the classes as a memory stream (?)
add the new class as code within existing files on disc
create the new class as a new file on disc (or cloud ?) in C:\Temp or elsewhere
the new class could be part of a partial class (either a real partial class in your application or an empty new dummy partial class)
In any case the project file would need to be auto-edited (by the vsix) to reference the new file(s). Presumably you want the project file reverted aferwards ?
And if, unlike me, you want to get down and dirty, you could always interfere with the IL, but you're on your own there !
As TarkaDaal says, without knowing why you need this it's not easy to provide a more definative answer.

How to re-use a user control in two Silverlight client applications?

I'm kind of new to Silverlight and I have a solution which has one web project (webApp) that provides remote services and two client applications (client-1 and client-2) that uses these services.
I have created a complex user control in client-1 that view/edit an object retrieved from webApp and I want to re-use this control in client-2.
The problem is, when you reference the service from the client apps, the types are "locally-typed". For example, MyClass defined in the webApp becomes client-1.MyClass in client-1 app. Using exactly the same object (reference) in client-2 app, it is now of type client-2.MyClass
If I create a library to host my control, I will have to add a reference to the web services and I will have a third type, lib.MyClass. We all know that client-1.MyClass, client-2.MyClass and lib.MyClass are all exactly the same class that was generated from web.MyClass but I can't find a way around this problem.
I'm currently looking at sharing the source code of the user control in each client application and having pre-processor defines in each project so I can do this in my user control code file:
#if CLIENT-1
using Client-1.WebAppServiceReference
#end if
#if CLIENT-2
using Client-2.WebAppServiceReference
#end if
Then the method that uses the type MyClass are using the correct "local-type" in each client app. But I'm having problem since there is no pre-processor functionality in the xaml and there is a reference to the application's namespace there that I need to be conditional.
There's got a be an easier way of re-using controls accross silverlight projects, no?? There is no way I'm going to have two copies of the source files for this control, on in each project!!
Thanks!

There are a couple of options that allow you to use shared entity classes across Silverlight projects/WCF service proxies.
Use an RIA class library
Use a portable class library
If you create your DataContract classes with either of the above, and then reference the library from both your WCF and Silverlight client projects, then the auto-generated code will use a reference to those shared classes (rather than the locally auto-generated classes). This should allow you to re-use your Silverlight UserControls between projects.
The difference between the two approaches is this. If you use the first approach (RIA project), then when you create files named "SomeEntityClass.shared.cs", the ".shared" tells Visual Studio to place a copy of the file in a mirror Silverlight project. The second approach (PCL) is a newer approach -- it allows you to create class libraries that are capable of targeting multiple platforms (.Net, Silverlight, Windows Phone, ...), with a reduced set of core .NET libraries.

I suggest you to dissociate the XAML and graphical stuff from any of Business logics and the like. MVVM is a very good pattern to follow.
After that, you can reference your UserControl from second project with the very useful functionality of Visual Studio "Add as Link"
Here how you can do it :
For the underlying business, you can make it available for both project, and linking these 2 with it.
Hope it helps

Visual Studio Express 2013 - Create separate c# code file?

The VS 2013 Express forum doesn't seem to exist at Microsoft so I'd like to ask here..
I am using Microsoft VS Express 2013 to create a C# project. I'd like to be able to add a whatever.cs file to the project so that I can put extra functions there instead of in the default Program.cs file. Back in the old days, we could import code files in C by using a #include but C# in the Visual Studio doesn't seem to do this.
I have been able to successfully add a .cs file, create a class within it, and then instantiate the class and call it's methods from within Program.cs but I'd rather not have to instantiate a variable and have to call functions like something.MyFunction() just to execute some code that exists in another file.
Is this even possible? If not, does anybody know why? I always like the #include in C. You could keep things nice and neat.

Files added to a Visual C# project are automatically "included" in every other file within that namespace. You do not need a using statement unless you change the namespace. Because of this, there is no equivalent of the "#include" directive from C/C++.
Now to handle your use case. C# is inherently object-oriented. It is not expected that you create a million functions and call them individually (like you do in C). So, if you want to use multiple files (and you should!) you have a few options:
Create a normal class (as you have already done) and instantiate it to call its methods. This is the preferred method, and you should be able to come up with plenty of classes for your program that make sense.
Create a static class. These don't have to be instantiated (you access them like MyStaticClass.MyFunc(); ). These are often used as "helper" classes. In general, use sparingly as they are hard to unit test/dependency inject.
Mark your class as partial. This allows you to define the same class over multiple .cs files. Again, this should be used sparingly (see Jon Skeet's answer: https://stackoverflow.com/a/2895068/1783619)

Where do I put classes when using Web Application project type of Visual Studio .NET instead of Website? (ASP.NET)

I have plenty experience creating ASP.NET Websites in the Visual Studio. But there is an alternative way to do the same thing that is through Web Applications, which have slightly different file structure.
Since I created my first Web Application I couldn't use classes (.cs files) in the App_Code folder anymore, they were not seen by the ASPX and ASHX classes unless were moved to the same file.
It happens that I use the same classes across many files and I don't want to have multiple copies of them. Where do I put those classes? There is any solution without creating another project?

We have been using Web Application project type in VS 2008 for all our projects and put our common classes in AppCode folder instead of App_Code folder. It works absolutely fine, we access our classes across all the pages in the application without any problem at all.

With Web Application Projects you have a lot more freedom. Just create subfolders under your project to hold your classes. For example, you could have a folder named "DAL" to hold the Data Access Layer items.
Optionally, you can create an assembly project and put your classes in there and just reference it from your WAP.
Ultimately the structure is going to boil down to how many classes you will have.

Why do you not want to create another project? This would be the simplest approach as all your classes would be housed in that assembly which you could project-reference in your web application and then have access to everything across the entire project.
I would highly recommend that you consider this approach.

I normally have three projects within a solution. The web app, the web library (base pages etc) and the DAL. This keeps everything clean.

Put them anywhere you want. I tend to keep the little project-specific helper classes and base pages in a /Helpers folder under the web project, but split out DataLayer stuff and general-purpose reusable helpers to their own separate projects.

I use /Shared/Classes for general purpose classes used throughout the site. I like putting the rest of the classes in a Classes folder where they are used such as /blog/Classes/.
-- EDIT--
The answer above was how I stored classes in Web Forms application projects. Now that I am using MVC, I store general purpose classes in /Classes and non-general classes in subfolders under /Classes such as /Classes/Blog. In short, Old_App_Code has been renamed to Classes. This seems like a natural extension to the naming conventions I see Microsoft using in MVC, plus it works with my old Web Forms pages too.

I highly recommend that you put all your classes (domain objects) in a separate project. This way you will be easily able to write test against your business layer (domain objects) and your classes will be portable. Portable means that you can send your DLL to another developer and he/she can easily reuse the classes you developed.