Welcome Guest ( Log In | Register )

Bump TopicReply to this topicRSS feed Start new topic Start Poll

Outline · [ Standard ] · Linear+

> How Do I make Multiple "Entry Points" in a .NET CO

post Apr 11 2018, 11:41 AM, updated 5 months ago

Getting Started
Group: Junior Member
Posts: 227

Joined: Dec 2005
I am new to .NET CORE but I have followed a few tutorials. The tutorials I have followed are basically "Hello World" types of programs where I make a small functional .Net Core application and I publish it. They are basically a DLL, I assume, and they run in some sort of system/container where they can run on any OS.

Even though the final product is a DLL, the code itself seems to be structured in a way where it is an actual executable application.

So how would I translate an actual C# DLL project into a .NET Core project? How would a project that is already designed to produce a DLL work in a .Net Core project?

Executables only have one entry point: static void Main.

.NET Libraries expose public methods which are all entry points in that sense.

An "entry point" in a program is where the operating system invokes an executable program file, the term does not apply to libraries. (and ASP.NET web-application files are really just libraries, the ASP.NET host just looks for certain exposed Page/Handler/Controller types). This applies to ASP.NET. Does it also apply to .NET Core? Also, when I ran my .NET Core applications, I did it from a special command line. So how would that work if I translated a DLL C# program into a .NET Core program?

post Apr 16 2018, 12:21 AM

Look at all my stars!!
Group: Senior Member
Posts: 3,785

Joined: Dec 2004
From: Metro Prima, Kuala Lumpur, Malaysia, Earth, Sol

I am not sure what you are trying to ask and im not a pro in term of dll. but some of the details you got are wrong.

First, void main is not an entry point, cause its not exposed, its not public, and its the application decision to run the void main, some .net application do not contain void main, especially vb.net programs.

Secondly entry points are like public functions, they usually perform something, and are not application by itself, u cannot see it in the application list, its not an executable, u cannot just "start" a dll. the dll need to be within an application, that mean without an application, the dll cannot run. Example, u cannot write an application, call the dll, and quit the application and expect the dll still running. The dll uses the main executable memory and only persists when the main application still alive, when the main application closes, windows will "clean" up all memory space or anything the application owns.

Dll can have 0 (which is useless) or multiple entry points, u can google easily with "dllimport entry point", basically the dll expose some functions for the developer or the operating system. Its more like a public function that can be called by many other applications. Instead of having a gigantic application with 0 dll, developers can split the application into many dll or plugins, which is easier to maintain, update or share among a team of developer, imagine you are 1 of the developer in a group of few hundred person, without dll, you need to compile the massive code which could take hours or days, if you split them into many smaller dll, everybody can work with a smaller piece of code and if anything goes wrong, just debug 1 small piece, instead of a giant codebase.

And dll is a good way for oem to work with certain devices, ie, a mykad reader have some very sensitive information like the key to access mykad, u cannot simply just release the code, which everybody can see the key, so u can hide it within the dll, and expose some functions to the developer allowing them to use the device without knowing those sensitive info. And dll usually have multiple entry points like
load - start the dll, let the dll initialize and load something into memory, without running this, will cause error accessing any functions.
user defined functions- like take in password to read the mykad(decide which level of security level. basic can only read basic info, higher can alter details, top level can even change the password of the mykad), read name, read photo, write(with certain password)
free - end the dll, release whatever memory, usually this is not needed, cause once your application ends, windows will do the clean up, but in older operating system, os wont do so, so its a memory leak situation.

To make an application, you just need to use that dll and call that dll in the correct sequence or order in your application, like i said b4, without application, dll cannot survive, basically your application is a host, allowing the dll to survive in your memory location.

This post has been edited by narf03: Apr 16 2018, 12:24 AM
post Apr 18 2018, 01:55 PM

New Member
Group: Junior Member
Posts: 36

Joined: Dec 2010

Hi, I'll try my best to give a slightly technical explanation which is easy to understand below.

.NET Core applications are meant to be cross-platform, meaning they can be run on any OS that has .NET Core runtime, thats why its extension is ".dll" when you build your project. In order to build Windows specific ".exe" files, i'll leave it to your google-fu skills, it has been answered many times on Stackoverflow.

QUOTE(Athono @ Apr 11 2018, 11:41 AM)

So how would I translate an actual C# DLL project into a .NET Core project? How would a project that is already designed to produce a DLL work in a .Net Core project?
I'll assume that your C# project still uses .NET Framework which is only available on Windows. Porting a .NET Framework project to .NET Core 2.0 may not be possible due to missing APIs which are Windows specific, however if your project does not use Windows specific APIs then you may be able to port your C# project to .NET Core. After building, your DLL may be referenced in other projects as usual.

Bump TopicReply to this topicTopic OptionsStart new topic

Switch to:
| Lo-Fi Version
0.0549sec    6.80    5 queries    GZIP Disabled
Time is now: 17th August 2018 - 03:20 PM