Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 30 21:07
    mpostol edited #632
  • Sep 30 21:07
    mpostol closed #632
  • Sep 30 21:07

    mpostol on master

    Move discussion from Gist to Di… (compare)

  • Sep 30 20:38
    mpostol edited #632
  • Sep 30 20:37
    mpostol edited #632
  • Sep 30 20:37
    mpostol edited #632
  • Sep 30 20:36
    mpostol edited #632
  • Sep 30 20:35
    mpostol opened #632
  • Sep 12 13:21
    mpostol closed #630
  • Sep 12 13:21

    mpostol on master

    Enhance/Improve README - - add … (compare)

  • Sep 12 13:00
    mpostol edited #630
  • Sep 12 12:59
    mpostol milestoned #630
  • Sep 12 12:59
    mpostol labeled #630
  • Sep 12 12:59
    mpostol assigned #630
  • Sep 12 12:59
    mpostol opened #630
  • Sep 11 19:11

    mpostol on master

    Added reference to playlist on … (compare)

  • Aug 18 19:21

    mpostol on master

    Updated graphics in the .pptx f… (compare)

  • Aug 15 21:16

    mpostol on master

    NetworkIdentifier is missing in… (compare)

  • Aug 15 21:13
    mpostol milestoned #629
  • Aug 15 21:12
    mpostol assigned #629
Piotr Szymczak
@Drutol
With having that working I think I can write some docs and tests.
Mariusz
@mpostol
@Drutol I have closed: ConfigurationFactoryBase - should allow loading custom configuration #312

@Drutol as I said previously the code is ready to read any custom configuration derived from ConfigurationData or wrapping the ConfigurationData. Because you must provide the following function (LoadConfig() ) used to load configuration (Inverse of Control) you can define any type as the type parameter of XmlDataContractSerializers.Load<TypeParameter> that meets the requirements. Additionally, you are not obliged to use XmlDataContractSerializers.Load<TypeParameter>, so, for example, you may load the configuration from resources if applicable.

    private ConfigurationData LoadConfig()
    {
      FileInfo _configurationFile = new FileInfo(m_ProducerConfigurationFileName);
      return ConfigurationDataFactoryIO.Load<ConfigurationData>(() => XmlDataContractSerializers.Load<ConfigurationData>(_configurationFile, m_TraceSource.TraceData), () => RaiseEvents());
    }

This method can attached to your instance of the ConfigurationFactoryBase (class derived from it) your custom configuration TypeParameter.
Because I had also a while to recover this idea I have decided to improve the implementation and make the ConfigurationFactoryBase generic to load any custom configuration. I have just finished the code and now I am going to improve the unit tests to provide examples for these two scenarios.

Anyway, you can immediately work on your custom configuration (inherited class or wrapper of ConfigurationData because the solution is ready and the improvement underway. Today I will commit the code, but the tests and kind of documentation will be available very shortly.

It has be done and unit test contains examples how to deal with custom configuration.

Mariusz
@mpostol

@Drutol i am going to resolve #321 . The question is quite open and relates to composition. In your application you are using Autofac and all Export attribute have been replace by manual type registration. In current library implementation, all Importplaces are located in the custom code only so parts could be easily injected using Autofac container. I am not sure if after modification the library some imports will be located inside the library (my stuff). Is it possible to make available commonservicelocator side by side in your code to avoid using the Import attribute.

I want to fix #321 before final release of your code, but I am not sure if it feasible just now because it could have impact on the software architecture.

Piotr Szymczak
@Drutol
If everything boils down to adding ServiceLocator.SetLocatorProvider then there's no problem for me. From what I understood you want the library to compose itself using some IoC/DI container but avoid enforcing implementation on the final user with help of CommonServiceLocator?
Mariusz
@mpostol

@Drutol Let me give you an example where I need ServiceLocator:

    public UANetworkingConfiguration()
    {
      if (ServiceLocator.IsLocationProviderSet && ServiceLocator.Current != null)
      {
        IServiceLocator _locator = ServiceLocator.Current;
        this.TraceSource = _locator.GetInstance<ITraceSource>();
      }
      else
        this.TraceSource = new TraceSourceDefault();
    }

it is located in UAOOI.Configuration.Networking. If it is not implemented the code do nothing. In this example we only switch off tracing.
Because the library depends on the ServiceLocator I am expecting that you will provide implementation of ServiceLocator.SetLocatorProvider. I believe it is application responsibility to provide this implementation.

Have a look on UAOOI.Networking.ReferenceApplication.MEF.ServiceLocatorAdapter because it provides implementation for MEF in the ReferenceApplication. My expectation is that you will do similar implementation for Autofac if it is feasible. I am pretty sure someone has done it already.

For sure, I am not going to compose the library, but the library needs some services that should be provided by a central (singleton) application container. I believe that the application as one whole should have one IoC/DI container.

Does it make sense for you? Handling of the DI container is very important portability issue, so I hope we could find a common solution. Dedicated solution for tracing is located in

  [Export(typeof(INetworkingEventSourceProvider))]
  public class NetworkingEventSourceProvider : INetworkingEventSourceProvider

Have you implemented it and if yes where ? This way I can remove dependency on ServiceLocator if there are some good reasons.

Piotr Szymczak
@Drutol
Yeah, providing the implementation is the responsibility of the end application. I don't mind adding ServiceLocator and Autofac supports it "natively". So no issues here.
I've had issues with EventSource mechanism using Xamarin/Mono so I didn't do anything with these.
Mariusz
@mpostol

@Drutol Great to know that ServiceLocator is supported by Autofac. Do you have any Unit Test to prove it works for ITraceSource ?

Do you mean EventSource is not supported by the Xamarin/Mono. It is crucial statement, because it is breaking feature and should be reported as the issue and replaced by something else in the library. I hope it s only used in the Networking.UDPMessageHandler. Anyway we should not just neglect it for sure.

Piotr Szymczak
@Drutol
I didn't do any extensive research but the same code that was working on .Net Framework in console app wasn't working in Android's environment. I've always found the EventSource to be more of a Windows thing with EventViewer and such. It certainly doesn't see much use in case of Xamarin apps.
Mariusz
@mpostol
@Drutol What tracing mechanism makes sens for Xamarin. What about Azure ? I believe some kind of run-time diagnostic should be provided.
Piotr Szymczak
@Drutol
Recently I've been using Microsoft.Extensions.Logging which is an implementation of Microsoft.Extensions.Logging.Abstractions it may be more "generic".
And additionally they have multiple implementations depending on the platform like Microsoft.Extensions.Logging.AzureAppServices or Microsoft.Extensions.Logging.EventSource
So it would be up to the end application which provider to use while library would just reference the Abstractions
Mariusz
@mpostol
@Drutol I appreciate reporting this an new issue and adding this proposal. I will investigate it but it seems that now it is hard to make any rapid changes.
Mariusz
@mpostol
@Drutol I have noticed that EventSource is defined in System.Diagnostics.Tracing so it should have been provided on all platform. It seems that if something is in the Standard lib it must be recognized as generic enough. I have used implementation for files, but it is very likely that Azure implementation exists as well for any platform.
Anyway selection of a common tracing mechanism is very important and must be backward compatible because you are not the only user. Now 4.0 is ahead so we can make breaking changes but good reasons must be on table. In this case we must prove that Microsoft.Extensions.Logging.Abstractions is more abstract that System.Diagnostics.Tracing - first we must define how to measure abstraction to make comparison in an objective way.
Piotr Szymczak
@Drutol
Mariusz
@mpostol
@Drutol I completely agree with it would be up to the end application which provider to use while library would just reference the Abstractions. Now the library depends on the NETStandard.Library only and It seems we should keep it intact.
Piotr Szymczak
@Drutol
Hmm, I understand that the less dependencies there are the better. Not quite sure how we can go around it though... like with CommonServiceProvider
EventSources are "nono" in my opinion anyway as right now they are enforced logging solution for end application. And as it appears not every runtime supports them
Mariusz
@mpostol
@Drutol we have two issues for now so lets go step by step.
  1. EventSource- Report new issue related to EventSource and collect all your findings and proposals. It is good starting point for further investigation and decision making. Lets do nothing with your application for now. We can state that this feature is not available on mono and that's all. Let me know how it works for you. We should also check the feature against official .NET Standard compatibility table.
  2. CommonServiceProvider if it is supported by the Autofac you should only make sure that you have registered all contract providers I need and it can be marked as fixed as far as I follow this issue.
Piotr Szymczak
@Drutol
Okay, so what other providers do you require to be registered in CommonServiceProvider? I already have there things like UDPMessageHandler and the other 3 implementations I forgot the names of (config, bindings).
Mariusz
@mpostol
@Drutol It seems the ITraceSource is needed for now.
Mariusz
@mpostol

@Drutol Let me return to portability issue in context of the EventSource type, because it is important for this project. EventSource is used in many assemblies and also external projects. It has been assumed that it is main tracing diagnostic data source. As I understand you have not composed it because of portability issue. There is official compatibility table:

.NET Standard Versions

How this table relates to your findings ? I will appreciate your comment. Main assumption for the project is that the library based on .NET Standard 2.0 is portable.

Piotr Szymczak
@Drutol

While https://raw.githubusercontent.com/dotnet/standard/master/docs/versions/netstandard2.0_ref.md does indeed mention the EventSource as a part of .NetStandard2.0 it's worth checking the docs page https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.tracing.eventsource?view=netframework-4.7.2 where they state:

Provides the ability to create events for event tracing for Windows (ETW).

I was browsing the https://github.com/dotnet/corefx repository and I've found inconsistencies when it comes to this class, with some RuntimeSpecific options.
I've also found this: https://github.com/dotnet/corefx/blob/c8c882c7366f2facfca4c8069de79da477dcf05b/src/System.Diagnostics.Tracing/ref/System.Diagnostics.Tracing.cs where implementation is just dummy one like in Mono. My guess is that runtime specific implementation comes in when on Windows and on other platforms it's just dummy class implemented only to be compliant with the specification.
Being only for Windows it's hardly portable as ETW is only Windows thing. I also personally consider them being very clunky to use, but that's just my opinion.

Mariusz
@mpostol

Do you mean that if an implementation does nothing it is compliant with a specification ? !
If the table says that

Xamarin.Android 8.0 and Mono 5.4 is compliant with .NET Standard 2.0 it means empty implementation ?

Can we prove something like that.

Piotr Szymczak
@Drutol
It's not about being compliant or not. EventSource is for ETW. ETW is only present on Windows. So it's impossible to implement it on other platforms.
At least that's my guess based on the files and docs.
The framework stays compliant but due to the nature of the class its implementation may be impossible.
Mariusz
@mpostol

We can prove that .NET 4.7.2. is for Windows and it doesn't meant that Standard 2.0 is for Windows . I am getting lost.

where you find statement that EventSource is for ETW.

Provides the ability to create events for event tracing for Windows (ETW).
If the underlying mechanism (on the OS side of things) being ETW is not available, how could such class be implemented?
That's what I bet on.
Mariusz
@mpostol

@Drutol I see, but in the ReferenceApplication I am not using ETW, even I am not aware about ETW. It seems that it is just typo copy/pasted from the very beginning. I am pretty sure it has nothing in common with Windows ETW. It seems we must treat the ETW shortcut as a general term. Let me summarize:

  1. If it is in .NET Standard => it must be portable to keep the idea intact
  2. If Microsoft states that it is compliant there must exist an implementation that do something not trivial
  3. In platform dependent implementation we should expect some limitations (e.g. ETW is not supported), but they must be clearly stated in the documentation (do we have something in this respect)
  4. The documentation for .NET Standard should be generic and implementation agnostic, therefore the wording problem should be reported to Microsoft. There are more mistakes, for example Starting with .NET Framework 4.6 - it doesn't make any sense in context of this abstract definition. It seems it is copy/paste problem.

I will appreciate any information referring limitation of the mentioned implementations Xamarin.Android 8.0 and Mono 5.4 - empty implementation should be recognized as an error for sure.

Let me also note that ETW is a sink, but we are talking about the source and the source could be associated with many different sinks. I have implemented the sink as a file (no ETW at all it works on XP) and I know an implementation for Azure again nothing in common with ETW, but in any case EventSource is used as the source.

Mariusz
@mpostol

@Drutol I have reported the problem:

dotnet/dotnet-api-docs#1723

Thank you for the feedback. Inform me in case you will find something more.

Piotr Szymczak
@Drutol

But wouldn't it be better to be even more abstract and go for a solution that supports EventSource as well as myriad of other providers? Regardless of what we do EventSource won't work on Mono while with abstract logging interface it would be left to end user's discretion.

EventSource is designed to interface with the underlying operating system's logging infrastructure, e.g. Event Tracing for Windows (ETW.aspx)) or LTTng on Linux.

EventSource is an implementation which is enforced upon end user and while it allows to attach some additional sinks it's still an implementation... OS dependent at that.

Mariusz
@mpostol

If you are sure it doesn't work on mono just report it will see the answer. Now we are talking about two things:

  1. Documentation - yest it has errors.
  2. Platform dependency - i have evidence that it works on many platforms not ETW aware - it proves that the documentation is wrong, but the error has been just reported.

I am pretty sure that EventSource is a generic solution and can be implemented on any platform somehow that make sense.
Anyway, thank you for feedback.

Piotr Szymczak
@Drutol
image.png
I'm scavenging info from the Internet.
I'm pretty lost with this issue too. :(
Mariusz
@mpostol
All, on branch 400 i have just commuted release candidate for 4.0. I am going to PR it to master and start working on final release of 4.0.
Mariusz
@mpostol
@AdamBorowiecki The release has breaking changes especially related to transport but it is preferred version to be used for external transport providers. It will make transport related components more robust against the future library changes.
@Drutol for your work it seems some definition has been moved to separate .dll
There are still some UT that fail so I will work to fix them soon. In the mean time please report me if there are some breaking features that must be fixed.
Piotr Szymczak
@Drutol
@mpostol 4.0 alpha is working correctly in my app :)
Mariusz
@mpostol
@Drutol Great, so I will go ahead. Many thanks.
Mariusz
@mpostol
@Drutol I have just released version 4.0.1. https://github.com/mpostol/OPC-UA-OOI/releases
Piotr Szymczak
@Drutol
:tada:
Mariusz
@mpostol
Now work is focused on the Export model. Scope: add UAModelDesingn generator implementing IModelFactory, Unit Tests, add command line application (tool).
The work will be conducted on the SemanticData branch and merged to master after accomplishing this milestone. The release is planned.
Mariusz
@mpostol
:tada: Object-Oriented Internet SemanticData ModelDesign Export 5.0.2-Alpha is available
The main goal of the Release 5 is to add export of the OPC UA Address Space to ModelDesign XML file.
This update comprises the following changes:
  • Updated the UA Address Space instantiation against OPC UA Specification 1.04
  • Updated UANodeSet schema up to 1.0.4
  • Published OPC UA Address Space Prototyping Tool (asp.exe) allows export to ModelDesign XML format.
    To get more visit the online documentation
    OPC UA Address Space Prototyping Tool (asp.exe)
Mariusz
@mpostol
New set of documents is ready for review on the SemanticData branch. Good starting point is Address Space Model Life-cycle.