Microsoft.Extensions.Logging.AzureAppServices or Microsoft.Extensions.Logging.EventSource
Abstractions
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.
EventSource- Report new issue related toEventSourceand 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.CommonServiceProviderif it is supported by theAutofacyou 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.
@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:
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.
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.
Provides the ability to create events for event tracing for Windows (ETW).
@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:
- If it is in .NET Standard => it must be portable to keep the idea intact
- If Microsoft states that it is compliant there must exist an implementation that do something not trivial
- 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)
- 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.
@Drutol I have reported the problem:
Thank you for the feedback. Inform me in case you will find something more.
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.
If you are sure it doesn't work on mono just report it will see the answer. Now we are talking about two things:
- Documentation - yest it has errors.
- 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.
@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.
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.
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)
OPC UA PubSub Main Technology Features
@joesan sorry for the delay, but I haven't got notification from this thread.
The answer is yes with the Ver 1.1. of the protocol.
The binaries are available here:
Networking -Internet of Things (IoT) Communication
There is a note:
This release contains modifications required to start interoperability testing against PubSub protocol version 1.10.
Standardization of the new version of the protocol is still in progress
AMENDMENT 6 - UADP Header Layouts (DOC/ZIP)
Now I am working on the protocol description using ABNF
OPC-UA-OOI/Networking/SemanticData/MessageHandling/
available on the Network branch.
Augmented BNF is defined in the document Augmented BNF for Syntax Specifications: ABNF RFC 5234
The document is available here
NetworkMessage.abnf
This update comprises the following changes:
- semantic-Data (Details in section SemanticData)
- updated against OPC UA Specification 1.04; new API
- added export to UAModelDesign
- documentation improved
- new code help documentation available
CAS OPC UA Address Space Model Designer is moving to open-source
Let me inform you that CAS OPC UA Address Space Model Designer has been just published on GitHub as the open-source:
OPC UA Address Space Model Designer
For now, it is a stand-alone project, but any ideas related to harmonization with your needs are welcome. Further development and priorities will be derived from community feedback. The old installation package is still available on the commsvr.com web-page:
http://www.commsvr.com/COInstal/UAModelDesignerPro/setup.exe
I am also in the process of moving the CommServer software family to open source. The master plan is available here:
CommServer - management of migration to open source
Any questions, suggestions, and proposals are welcome.
OOI and ASMD harmonization
Visit the harmonization to learn moreI have commenced a preparation stage. All feature requests are gathered as the comments of mpostol/OPC-UA-OOI#400.