We Keep Coding

C# .DLL Library - Best Practices for Console and Form Windows apps

Over the years I've written my own Windows .dll in C# which includes many objects and functions that I normally use. Up until now, all my programs have been console applications so my dll functions write their status, errors and output to the console. For example: "Loading polygon file : Fred.txt" or "Imported 268 polygons from file". Now I'm starting to write Windows Forms programs and I want to reuse the dll functions, but obviously I can't write to the console for a Forms app.
Does anyone have any suggestions as to the best way to handle a dll which contains functions to be used for both console and forms programs? Is it best to have two versions of every function? Are there ways to tell if a function is called from a Form and not write to the console?
Thanks,
Mark

Do you want to display the messages in your windows forms application? Typically DLLs don't deal with UI operations, such as displaying messages. They can however deal with logging, if that's what you're actually looking for. I would say you should look into a logging framework like NLog and implement that in your DLL.
If you have a WinForms project that references the DLL, you could pass information up from the DLL and display at the UI level. It's a question of proper application architecture. Ideally, the DLL would know nothing of the way it's being used, i.e. from a console application vs. a WinForms app.

"but obviously I can't write to the console for a Forms app."
That's not at all true. You could allocate a console, and write the information to it. So you'd have your forms, and also a console that's writing your output. That works great for debugging.
Or, you could redirect the console output to a file. Just pass a reference to an open StreamWriter to Console.SetOut, and everything that you were writing to the console goes to that file. It's a great way to do some informal logging.
If you're wanting to display the methods' outputs and error messages in the Windows Forms app, then you have to give them somewhere to send the output. That will probably require a lot of rewriting your library methods. The idea is that, rather than writing to the console, those methods would call an output method that you supply. That method would probably be part of an interface. Still, that's not a particularly good way to do things because it assumes that your library knows how you'll want information reported in every user interface scenario.
In general, you probably don't want worker methods to supply user interface output. Logging, sure, but you probably don't want the function that loads data from the file to output to the user: "Loaded 287 records from file." Instead, you have something like:
// in your console program
List<Thing> things = LoadThingsFromFile("filename.txt");
Console.WriteLine($"Loaded {things.Count} things from file.");
// in your Windows Forms application
List<Thing> things = LoadThingsFromFile("filename.txt");
StatusLine.Text += $"Loaded {things.Count} things from file.";
StatusLine.Text, of course, is just an example. You might have this in a scrolling list or pop up a message box, etc. The point being that you want the UI code rather than your processing code to decide how information should be communicated to the user.

Alternate running a console Application as Exe and WinExe [duplicate]

This question already has answers here:
Show Console in Windows Application?
(12 answers)
Closed 6 years ago.
I have a C# console application that I am running with its output type set to "Windows Application" to prevent the console from being seen during normal use. However, I would like the option to alternatively run the program as a console application at will, in case the user wanted to troubleshoot and view the console's output.
Is it possible to pass a command-line argument to the executable to either run the application in "Console" mode or "Windows Application" mode depending on the user's desire? If not, is there any other way to change on the fly if an application will show the console or not?

I think you have an X-Y Problem. The root problem is that you want the user to be able to run either a console or WinForms program that both do the same thing. One solution would be to have a single program that can run as both, but as #roryap pointed out, this is impossible.
A second solution would be to put the business logic of your program into a separate library. You can then write a console program that accesses this library and a WinForms GUI that also accesses this library. The user then decides which program to run. This is a tried-and-true method of separating an application into multiple layers. I recommend you go this route. You'll find that your user-facing layers (console, WinForms) are small. In the future, if you want to make a Web front-end, or a WPF front-end, you only need to write the front-end part, the business logic layer won't change.

No, you can't. There's a fundamental difference between a console application and a winforms application that goes very deep. Once the application is compiled, it cannot be changed at run time.

Determine whether the class library is called from a windows based application

This is based on C#. I am having a classlibrary in which I would like to know specifically if its being called from a windows based application
I searched a lot but all I found was code to know if it was called from a Console application.
I only want to know if its called from a windows based application or not
Please Help

If you want to know whether the application is running as a service or system app and thus cannot display a dialogue, test the state of Environment.UserInteractive.
There is no easy way to determine if the application is a windows or cmd-based application. For example, I might build a winforms-based application that doesn't create a window and instead runs as command-line style application by not opening a window.
Two (not necessarily reliable) ways of testing if it's a windows-based app would be to test Application.OpenForms (if it contains forms, then it's a windows app) or Environment.GetCommandLineArgs() (if 0 args, assume it's a windows app).
If you absolutely need to know whether the app is a console or windows one, then you need to step out of the world of managed code and start delving into the exe file using unmanaged C++ code. There is just one byte difference between the two in the PE header of the exe file: Subsystem is set to 2 for a windows app and 3 for a cmd app. See http://msdn.microsoft.com/en-us/library/ms809762.aspx and http://support.microsoft.com/kb/90493/en-us for details if you really want to do this.

c# shadowcopy example

I need to update my executable with also the dll linked..
I've read about the AppDomainSetup.ShadowCopyFiles but I'm in trouble trying the right steps to do what I need
the question are:
the shadow copy I need to create only when I notify an update or each time I launch my executable?
what is the right step to copy and update the dlls and the .exe?

Creating a shadow copy is not going to update your application. The general sequence of auto-updating requires a third application that manages the process. It looks something like this.
Main application finds update and downloads update files to temp location
Main application launches updater application and terminates itself
Updater application copies update files over main application files
Updater application launches main application and terminates itself
Obviously there is going to be error handling logic built in to this. But that is the general idea. Shadow copies are nowhere in there.

Making use of the shadow copy feature of .NET is not a bad idea. It will allow you to update your assemblies without having to exit the application BUT you will need to restart the application in order to run the updated version. Shadow copy will simply allow you to overwrite the assemblies and nothing else.
Note that you cannot enable shadow copy on the default AppDomain. This means that you will need a loader that will create the AppDomain, and execute your application. Have a look at this answer for the steps you need to take and for a simple implementation.
If all you want to do is allow updates to be installed without having to exit the application then this is the simplest approach I can think of.
You should also have a look at Microsoft's ClickOnce technology. It solves a lot of the common problems of deploying and updating .NET GUI applications.

c#- what steps do i have to go through to convert winform app into console

i have a very simple winforms application.
i do not use the forms object at all. i would like to know what i need to delete or change in order to convert this app to a console. i mainly just need to get rid of all the unneeded references and such
please let me know what steps i should take to do this?

It really depends on how did you code it at first and what pattern are you using. If you have made clear distinctions of what is the back-end and what's not, then you would only have to create a new class to act as the program's Main and change the project's Application Typeand the Startup Object in the project's properties.
If you have all the back-end code intertwined with the winforms then you first need to separate them and then proceed to with the above steps.

You can change the project settings to create a Console Application instead of a Windows Application (just hit Ctrl+Enter on the project in the Solution Window, and make that change).
That will compile the application as a Console Application, and you'll get a console. However, you'll still get your forms. If you want to not have Windows Forms, you'll need to remove the forms, and replace their functionality with command line arguments or configuration. You can then remove the Windows Forms references, and it'll be converted.

Create console app and move the simple code over