#63 Suggestion: Changing assembly names of TheLib.Net libraries
The current names
theportablelib.dll thecorelib.dll ...
seem inconsistent with the usual Dotnet naming. As we adopt to the environments we are working in, in terms of style guilds and naming conventions, I suggest, we should use more Dotnet-like names, like (Suggestion 1)
The.PortableLib.dll The.CoreLib.dll ...
or (Suggestion 2)
The.Portable.Lib.dll The.Core.Lib.dll ...
or (Suggestion 3)
The.Portable.dll The.Core.dll ...
or (Suggestion 4)
TheLib.Protable.dll TheLib.Core.dll ...
This is just a suggestion I came up with as I now started to use these Libs in more of my projects, too. If we change the naming of the libs, we should decide rather soon, before too many projects depend on these.
I, personally, like suggestion 1.
Suggestion 2 seems to imply there are namespaces "Protable" or "Core".
Suggestion 3 is nice but too short. Especially "The.Core.Dll" seems like something some other applications could use as name.
Suggestion 4 is not consistent with the main namespace.
I would not add the namespaces to the library names as the root namespace of the library could/would not match. The root namespace is normally "The", because the libraries for .NET, .NET portable, Windows Phone and Windows Store contain the same content as far as possible, with conditional compilation symbols.
The only thing I am currently considering is the .NET library, which is split in the "core" library and the WPF library to remove this dependency. It would be a cleaner solution if we had only one library for each platform (.NET portable, .NET, Windows Phone and Windows Store).
I would include the namespace, or at least the 'the', to avoid conflicts with other libraries.
We currently have:
I think, the least we should do, is change from lowercase to PascalCase to match up with the DotNet naming style.
If we re-design for platforms, how do we separate for applications using "Windows Forms" and application using "WPF"?
E.g. thecorelib contains some classes for the Log which cannot be implemented in the portable lib.
If we re-design for platforms, naming following suggestion 4 could be a nice thing to do:
e.g. "TheLib.Phone.dll"
I see a variety of issues here:
First, I am already excessively using theportable.lib and thephone.lib in a variety of projects. Therefore, I am obviously reluctant to change the project and/or solution name.
Second, I currently envision that we have a portable class library that contains as much of the code as possible. With this portable library, we should have platform libraries for .NET full, the phone and WinRT. Those libraries could provide (i) platform-specific extension methods and (ii) platform-specific classes. The latter should use shared/linked source whenever possible in order to have a consistent programming interface over all platforms.
The main issues here are the already mentioned UI part and the .NET FW version. Currently, we are on 4.5 for most of the libraries. This will probably not stay forwever. The question is whether we will provide even more different binaries or if we are always "edge".
For the UI part, I currently tend to make the one full library dependent on WF and WPF. As we are 4.5, any client should have both. Furthermore, I often need WF in my WPF projects, so this is really no issue. The question is whether it is an issue other way around. I mean, a compound library will probably never work on Mono...
I would not rename the msvs projects.
We could rename the output binaries to one of the more fitting schemes and we could add a post-build event creating copies with the current (legacy) names. New projects could use the new names and older projects would work without changes. Additionally, if we keep the names and just change to PascalCase, nothing will change for the client projects.
I am currently using theportable.lib in many projects and thecorelib in a few projects. At the moment I do not use the other projects at all.
I see no real issue in mixing WF and WPF in one platform-specific library. (TheDesktopLib.dll?)
For the 4.5 issue: I believe the msvs projects can do this for different configurations, although the msvs GUI cannot edit this. For now, I am fine with "edge" development. I think we can postpone the decision on that one.
And, I do not care for Mono.
I have been working with a VS 2013 version of thelib for some time and came to the conclustion that the idea of the portable library with PF specific extensions will not work. The reason is that the concept of portable libs is a total mess. The different portable subsets do not share a common part that you can rely one, wherefore it will be necessary to have more than one PCL. For example, adding WinRT 8.1 support to the current PCL will strip ObservableCollection from the subset, ie the upgraded version has less features than the old one.
I think the only viable solution is linking projects, ie there is TheLib.Net, which is the basis (full desktop .NET) and a set of libraries only having a subset that link the code (eg TheLib.NetRt8.0, TheLib.NetPhone7.5, TheLib.Net3.5, etc.). I am testing that in a branch now.