I found the WebSockets-Namespace in the .NET core documentation.
There is an abstract WebSocket class, I understand that I cannot instantiate this class directly, do I need to inherit the class and implement it by myself or is there a complete implementation somewhere else?
Link to documentation
I googled a lot, but everything I can find is for ASP.NET core.
Microsoft do provide a client implementation of the WebSocket class called ClientWebSocket.
You can find it as a NuGet package: System.Net.WebSockets.Client
As far as I know, this is the only official and available implementation. If you need more than this, I do believe you have to find a 3rd party library or implement it yourself.
Related
I am using Web->Service->Data layer architecture and in order to do some logging with log4net I would need to install to all these three projects. Also I want to decouple the concrete logger in case I would want to change it later in the process. I am using Autofac IOC for injection. Is there a way to add log4net package once and use it between the layers? I found some blog posts about this but there was not much code so I could not get a good grasp on it, you can either give some directions or an explanation of how to achieve this.
Thanks for your time
There's a really small assembly which only contains a logging interface, no implementation, that you can use to decouple your assemblies from your logging implementation. It's called "Common Logging" and is available in NuGet.
You add a reference to Common.Logging in all your projects that need logging, and then through XML configuration or in your bootstrap code you can inject a concrete logging implementation, such as Log4Net. It also supports other logging frameworks.
I am trying to use the Caliburn.Micro framework.
However the first page of the documentation refers to a class that doesn't exist anywhere, called Bootstrapper.
Unlike other versions of Caliburn Micro the WinRT version doesn't use a Bootstrapper, the non ranty reason for this is that Windows.UI.Xaml.Application exposes most of it's functionality through method overrides and not events. Therefore it makes sense to have a custom Application rather than forcing the developer to wire the application to the bootstrapper.
This quote is taken from the documentation on Working with WinRT from the official wiki documentation.
You can look at the complete list of documentation wikis at the official site at Codeplex.
This is an issue with the WinRT version of Caliburn.Micro where there is no bootstrapper type.
I found this WinRT-specific tutorial that covers things:
i've been trying to get my head around on EntLib 5.1 Unity and it's confusing me a lot http://msdn.microsoft.com/en-us/library/ff660864%28v=PandP.20%29.aspx.
Could anyone please tell me on what type of scenario I can use Unity?
I've a requirement to load the specific dll based on request type. Can Unity be used on this scenario?
Thanks a lot.
For dynamically loading DLLs, you may want to take a look at MEF.
Unity is for decoupling dependencies among classes to make it easier to write testable, reusable code.
It is an Inversion of Control (IoC) container library that makes it easier to do Dependency Injection. There are numerous examples on Stack Overflow. Note that you can configure Unity in code (my preference) or with a configuration file.
Is it possible to include a .net 3.5 framework DLL in classic asp?
You will need to expose this .NET assembly as a COM object. This could be done using the regasm.exe utility. For this the types that you need to use or the entire assembly must be decorated with the ComVisible attribute.
Then consume the COM object from classic ASP as you would with any normal COM object.
Yes, it's called creating a COM-Callable Wrapper.
Here is the MSDN Documentation
The link that pops up for the Code Project article in Google is, surprisingly, not the better one. You'll want to check out this one: Exposing .NET Components to COM It's the best. Complete step-by-step tutorial.
It's worth noting that in a former life I had to develop and support a .NET application which was exposed to some COM-based integrations - and simply slapping ComVisible on my classes was putting me in a world of hurt. Pay attention to the author's explanation of the Interface Types in that article... that article is a gem.
Excerpt:
Previously I was using AutoDual,
however Heath Stewart[^] pointed out
this was not the best method to use as
it can create version-related problems
in the long run. After reading a
little more I changed the code to use
ClassInterfaceType.None which forces
our class to gain access only through
our interface. This keeps everything
viable during changes to the class in
the future.
I want to isolate all my code from the IoC container library that I have chosen (Unity). To do so, I created an IContainer interface that exposes Register() and Resolve(). I created a class called UnityContainerAdapter that implements IContainer and that wraps the real container. So only the assembly where UnityContainerAdapter is defined knows about the Unity library.
I have a leak in my isolation thought. Unity searches for attributes on a type's members to know where to inject the dependencies. Most IoC libraries I have seen also support that. The problem I have is that I want to use that feature but I don’t want my classes to have a dependency on the Unity specific attribute.
Do you have any suggestions on how to resolve this issue?
Ideally I would create my own [Dependency] attribute and use that one in my code. But I would need to tell the real container the search for my attribute instead of its own.
Check out the Common Service Locator project:
The Common Service Locator library
contains a shared interface for
service location which application and
framework developers can reference.
The library provides an abstraction
over IoC containers and service
locators. Using the library allows an
application to indirectly access the
capabilities without relying on hard
references. The hope is that using
this library, third-party applications
and frameworks can begin to leverage
IoC/Service Location without tying
themselves down to a specific
implementation.
Edit: This doesn't appear to solve your desire to use attribute-based declaration of dependency injection. You can either choose not to use it, or find a way to abstract the attributes to multiple injection libraries (like you mentioned).
That is the basic problem with declarative interfaces -- they are tied to a particular implementation.
Personally, I stick to constructor injection so I don't run into this issue.
I found the answer: Unity uses an extension to configure what they call "selector policies". To replace the attributes used by Unity, you just code your own version of the UnityDefaultStrategiesExtension class and register you own "selector policies" that use your own attributes.
See this post on the Unity codeplex site for details on how to do that.
I'm not sure that it's going to be easy to do the same if I switch to another IoC library but that solves my problem for now.
Couldn´t you just setup your configuration without the attributes, in xml. That makes it a bit more "unclear" I know, personally I use a combination of xml and attributes, but at least it "solves" your dependency on unity thing.