Comments by CBennigton (Top 37 by date)

oh, wow. So then a Library has many physical forms. As you said could be a ".dll file", an ".lib file", or anything else... I did not know that. Thank you for informing me on that :)

But in C# context it seems like the physical form of a Library will always be a dll file. Would you agree?

After installing packages via nuget and viewing their contents in visual studio, it just shows dll files (aka: assemblies/libraries) and not lib files.

So then the physical presence of a Library is NOT a dll file?

Hey Richard :) much time has passed since the time I made this post.

I have been deeply studying what is a library and a package over the past few weeks.

I now understand what you meant when you said "Of course a library has a physical presence."

I never understood why so many developers kept claiming that a Library does not have a physical presence. When in fact it does.

Accroding to documentation https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/dynamic-link-library ---. "A DLL is a library that contains code and data that can be used by more than one program at the same time."

Thus, the physical presence of a Library is a DLL file. While the physical presence of a Package (Nuget Package) is a NUPKG file.

But just as a confirmation, would you agree with what I mentioned above?

In terms of what the physical presence of a Library and a Package is.

It would mean a lot to me if would reply back. Thanks...

Yes, of course, it made more sense after reading https://microsoft.fandom.com/wiki/Microsoft_.NET_Languages thanks for pointing that out.

Personally I felt I was already at a point were I can ask this these kinds of questions. It seems I have a few knowledge gaps that I have to fill.

Thanks for the assistance. If you decide to create a seperate solution to this post I will also accept it as an answer. If not, it was still much appreciated.

Yes, I am aware that C# is a .net language (including C and C++) and how .NET Framework and .NET Core do in fact support the C# language.

Thus, I assume that document does in fact apply to C#?

So then that document does apply to C#? Lol

Sorry mate, I don't mean to sound redundant but you worded you initial comment weirdly (and I mean that kindly) that now I feel like i'm misintrepeting every other comment after it.

"But that only applies to .NET. C/C++, Java etc have their own formats." --> are you saying that document does not apply to C#?

Great anology!

By the way I also just came across this document https://docs.microsoft.com/en-us/dotnet/api/system.io.packaging.package?view=net-5.0 which plainly states the physical format of a "package" is a zip file and since packages are distributed via nuget it will have the file extension .nupkg as im sure you already knew. :)

Yet I cannot find anything on libraries?

"Of course a library has a physical presence. How would your programs use it otherwise?" Good point :)

Concerning a "Package" though, it's physical presence is in fact "a single ZIP file with the .nupkg extension" correct?

unless I am misinterpreting the MS documentation.

If the physical presence/form of a package is a a single ZIP file with the .nupkg extension, then what is the physical presence/form of a Library?

I am aware you said knowing that is unimportant but up until now many have said that a package has a physical presence while a library does not.

Oh ok, now I understand what you meant. Thank you correcting me on that :)

However, a "Package" unlike a "Library" does have a physical form correct? Being a single ZIP file with the .nupkg extension and is container for assemblies (dll files)?

The Microsoft documentation https://docs.microsoft.com/en-us/nuget/what-is-nuget states ---> "Often such code is bundled into "packages" that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages". It also stated "a NuGet package is a single ZIP file with the .nupkg extension"

Unless I am totally misinterpretting the above statement made in the MS document.

"You may have something like the .NET library which is made up of one or more packages (physical downloadable DLLs)." ---> Are you saying that a Library is a container for packages?

After reading the statement you made "A Package is mostly delivered by a Package manager like NuGet", I did more digging on that and I actually came across the following Microsoft documentation https://docs.microsoft.com/en-us/nuget/what-is-nuget which states "Often such code is bundled into "packages" that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages". It also stated "a NuGet package is a single ZIP file with the .nupkg extension"

A Package is a physical thing (being a single ZIP file with the .nupkg extension) and is container for assemblies (dll files). Without your input I probably would not have been able to figure that out. Thank you.

As for what is a Library and what it contains, after inspecting the links you provided it still did not make sense to me. Specifically when looking into the link "Create a .NET class library using Visual Studio"

It gave me the impression that a Library is an "application project" that we create. Then when looking into the code examples it has a namespace and a class called "UtilityLibraries" and "StringLibrary".

So then what exactly is a Library? Is it an application project, a namespace, or a class type?

Well such a type must have special name given to it, right? Not sure if such a term exists. According Dave Kreskowiak no such term exists. If that's true I'll just stick to calling it a "top level type".

Hopefully the resource BillWoodruff recommended will have the answers I'm looking for.

That is true. The term "top level" has no official definition in any C# documentation. It's only an assumption I made from the code comment Jon made. But if "top level namespace" refers to a namespace not defined in a named namespace, then I would asssume "top level type" only refers to a type not defined in a named namespace as well.

Those are not my words. I was reiterating what user BillWoodruff said (See comments outside of the solution). I am sure the individuals that wrote the docs are excellent programmers but I guess not everyone feels that way.

Awesome. After looking into at the sample pages provided by amazon it looks like a great read. Thanks for the recommendation.

You're alright. Sometimes tough love is best way to teach / give someone advice.

Once again thanks for your advice and I will absolutely read your comments on the thread you mentioned. As a final note I added a comment on the other post I made. Perhaps you can give me your insight on what I mentioned there. But all in all thanks.

If I may add on one more final detail to this discussion, a well known C# programmer by the name of Jon Skeet even uses the term "top level type".

If you look at his solution https://stackoverflow.com/a/9443365 in the following Stack Over Flow post he actually refers to the class defined directly under the global namespace as the "top level type" rather than the class defined under named namespace Foo as the top level type.

Which as a result, is another reason that has led me to believe that only types (structs, enums, classes, interfaces or delegates) defined directly under the global namespace (e.g. global::TopLevelType) and thus, not referring to types defined in a named namespace, are called "top level types".

You are probably already annoyed by me asking these kinds of questions but if you can give me your insight on what I mentioned above (if anything that is) i'd appreciate it. Thank you for your time. I hope to hear from you soon.

Awesome. I have accepted your solution as the answer. As I told BillWoodruff I do believe understanding the semantics are important along with actual programming. Else why would someone bother with reading documentations, articles or video tutorials. Thanks for the help.

But isn't learning the semantics the foundation of programming?

I had no idea that "The people that write those docs are often technically limited, low-status, employees." I do think every now then for someone to acknowledge the sementatics. Else documentations and online resources wouldn't exist.

Very true. I have come across my fair share of inconsistencies in docs and tutorials. Thanks for the heads up :)

As a final quesiton though even though "Microsoft" alone is not part of the list, in your opinion would you say it is still considered a sytem-defined namespace?

As for the question itself, i'm actually writting a paper on Namespaces and i'm trying to understand the concrete details of it. I really appreciate all the help so far.

I mean if we are being very specific here then I would say "NO, namespace Microsoft is not in the list" as shown in the lastest version of the .Net framework 4.8

I see sub-namespaces defined under namespace Microsoft such as: Microsoft.Activities.Build, Microsoft.CSharp , etc... which are found in the list, but it does not list just namespace "Microsoft" as part of the list. Thus, I am starting to think that namespace Microsoft is not a system-defined namespace. I would appreciate if you could check that out for me.

Concerning namespace System, I do see namespace System and the sub-namespaces defined under namesace System are in the list. So I have no problem there.

"All of the namespaces defined in the .NET API are 'system' defined." --> So then I take it namespace Microsoft is in fact a "system-defined namespace"?

I did in fact look in the .NET API browser and "yes" namespace Microsoft is in fact in shown in the .Net API browser.

However, my confusion is, because "system" is a part of the term "system-defined namespace" my thoughts are that "system-defined namespace" may only be referring to namespace System and any namespace defined under namespace System. But I am unsure. Hence my question concerning namespace Microsoft.

As for what is a "top level type". Even though it's not an official C# term such a term its seems correct that a type defined directly under the global namespace (not in a named namespace) is called a top level type. Since as stated a namespace defined directly under the global namespace is called top level namespace.

Not sure if you agree with that, what do you think?

As for what is a "top level type". Even though it's not an official C# term such a term its seems correct that a type defined directly under the global namespace (not in a named namespace) is called a top level type. Since as stated a namespace defined directly under the global namespace is called top level namespace.

Not sure if you agree with that, what do you think?