i have a silly question regarding DependencyService. I am developing a mobile application in Xamarin Forms. I have just been reading about Dependency Service. If I am correct which i am most likely not and please correct if I am not, Dependency service is a class that is responsible for "translating" difference between droid and ios and its used for custom rendereds? So do i have to implement it in my solution?
My situation is that I am currently already connected to SQLite and I followed some tutorial which did not inform me about dependency service and this is how i initiate the SQL connection in my class.
public UserService()
{
_conn = DependencyService.Get<ISQLiteInterface>().GetSQLiteConnection();
_conn.CreateTable<User>();
}
If I implement interface dependencyservice will that somehow affect my sql connection?
All dependency service will not have implementation on android and ios. Dependency service is a way to hold single memory location. In this scenario all the functions related to sql connection is implemented in forms .net standard library. So it hold a single memory location, you can call the function anywhere from your project without creating the object. But the key thing is that you should register the dependency service
Related
I have a .NET Core console application which instantiates some public classes with some public properties. It runs a loop which under certain conditions modifies these public properties. These properties are updated several times a second for the lifetime of the application.
Now I want another application with a user interface to present the data from the console application. How would I from one application get data present in the public properties of another application?
Not needed
I am only interested in public properties in public classes. I am not interested in private properties or fields or internal classes.
The properties are very frequently updated, so I do not want to write to a file. Nor do I want to log to some cloud service such as Azure Application Insights.
I would rather not do extensive or intrusive modifications to the console application (such as writing to a named pipe or a network socket) just for the other application to be able to read the data.
Thoughts
Is there any attribute I can annotate the classes or their properties with?
Do I have to refactor the console application into a class library that both the console application and the UI application reference? This would move out all the code into a class library and leave the console application with just a static main method that does one method call to run the code in the class library.
Can my UI application attach to the process of the console application?
To communicate between processes, you're limited to a few practical options (none of which you seem to want to do):
Named pipes
Some sort of socket based communication (not WCF in this case because you're using .NET Core)
This could be a custom protocol between your applications.
Could use an external message broker (e.g. RabbitMQ).
Could send UDP messages from the console app.
File based communication (doesn't seem ideal for your scenario given how chatty the interface is).
I solved this using System.Runtime.Loader.AssemblyLoadContext.
I load the assembly into my application at runtime and then instantiate its classes and read the public properties from my instance.
class Program
{
static void Main(string[] args)
{
var fileName = #"C:\temp\foo.dll";
var assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(fileName);
var type = assembly.GetType("MyApplication.Car");
dynamic carInstance = Activator.CreateInstance(type);
Console.WriteLine(carInstance.Color);
}
}
Another way to solve this was by importing the project as a project reference. This way I benefit from strong typing.
I'm trying to create an end-to-end Application Map using Application Insights. Note all dependencies and metrics are captured and sent using the SDK.
Take the following scenario:
Windows service (batch processing) > (calls) WebAPI > (queries db)
I have 2 Application Insight resources - Windows Service and WebAPI. Both are capturing metrics but in isolation. How can I create a dependency using the SDK between resource 1 (i.e. service) and resource 2 (i.e. WebAPI)? I need to be able to view the Application Map for resource 1 and be able to see the entire end-to-end view of windows service > web service > db.
I can currently see only windows service > WebApi (App Map resource 1) or WebApi > db (App Map resource 2). Need to bring both together somehow?
Application Insights sdk only collect dependencies automatically for HTTP dependencies. Also it only works when the application insights profiler is running on the machine (often installed on azure websites through the Application Insights Extension).
If you happen to be in one of the situations where the new beta sdk is not collecting dependencies for you. You can do that on your own by writing a little bit of code yourself.
The sdk's autocollection code is open source and you can use it to guide you as to how to track these dependencies. The idea is to append the dependency telemetry's target field with the hash of the target component's instrumentation key and set the dependency type to "Application Insights".
Here is how to compute the hash: Compute Hash
Here is how to add it to the target field and set the right dependency type on the dependency telemetry object: Add component correlation to DependencyTelemetryTarget
A little word of caution. There may soon be a change to the format in which the target field is captured / the name of the dependency type (see this discussion). If and when that happens, it would be an easy enough change for you too.
My recommendation would be to use the same Application Insights resources (e.g. instrumentation key) for both your Windows Service and Web API.
You can separate your telemetry for those two services by adding a custom property indicating the service for all telemetry you emit. Easiest way to do this would be to implement a telemetry initializer (see here for documentation).
It is not possible today. Possible ways -
Use a single InstrumentationKey and identify by a custom property (as
suggested by #EranG
Export the data for both the apps and do your own thing
Please vote on this uservoice. Product team is already considering implementing this functionality in future.
I have an application that consists of a web application, and mutliple windows services, only one windows service is installed depending on what version of the backend sofware is used.
Currently, Data is saved by the web app in a database, then the relevant service is installed and this picks up the data and posts it in to the backend system that is installed.
I want to change this to use WCF services so the resulting data is returned directly to the web app.
I have not used WCF services before but Im assuming I can do something like this.
WebApp.Objects.Dll - contains Database objects, eg PurchaseOrder object
WebApp.Service.Contracts.dll - here I can describe the service methods, this will reference the WebApp.Objects.dll so I can take a PurchaseOrder object as a parameter
WebApp.Service.2011.dll - This will be the actual service for the 2011 version of the backend system, this will reference the WebApp.Service.Contracts dll
WebApp.Service.2012.dll - This will be the actual service for the 2012 version of the backend system, this will reference the WebApp.Service.Contracts dll
So, my question is, does the web app need to know the specifics about what backend WCF service is used? I just want to call a service with the specified Interface and not care about how its implemented or what it does internally, but just to return the purchase order that was created in the backend system (whether it return an interface or a concrete class)
Will i be able to create a service client without needing to know whether its the 2011, or 2012 WCF service being used?
As long as you are able to use the exact same contract for all the versions the web application does not need to know which version of the WCF service it is accessing.
In the configuration of the web application, you specify the URL and the contract. However, besides the contract there might be other differences between the services. In an extreme example this might mean that v2011 uses a different binding as v2012 of the backend - which is not very likely from your description. But also subtle differences in the configuration or the behavior of the services should be addressed in the configuration files. E.g. if v2012 needs longer for an action as v2011 does, the timeouts need to be configured so that the longer time of v2012 does not lead to an expiration.
Let me start with a little setup info... I am using the repository pattern and dependency injection via Unity. The repository is implemented via Linq-To-Sql. I inject my repositories into class constructors in my web project. The repositories have a PerWebRequest lifetime.
I have implemented a few SignalR hubs and have setup a Unity dependency resolver for SignalR. I'm injecting the same repositories into the hubs using the same Unity config file, which specifies these repositories are PerWebRequest also.
Now the punchline... I ran into a problem where the web project would update an Linq-To-Sql entity and the SignalR hub would read that entity and not get the updates. I have "solved" this problem by clearing the Linq-To-Sql cache before reading the entity in the SignalR hub; DataContact.Refresh() didn't update the entire object graph.
My DataContext for these repositories used in hubs are also PerWebRequest but it seams that the SignalR hubs are using a separate DataContext that does not get destroyed after the web request completes. It appears they are acting as singleton instances instead.
Do SignalR apps run in their own process and therefore my DataContext access from the hubs is a separate DataContext in that separate process?
How could the DataContext in the SignalR hub be instantiated with a PerWebRequest lifetime if it a separate process, apart from the web request lifecycle? Also, how does it seemingly act like a Singleton?
It's a while I don't use stuff like Linq2Sql or concepts like PerWebRequest, so I'm not 100% sure, but if I'm correct in saying that PerWebRequest is definitely tied to the lifetime of underlying HTTP requests, then those will hardly work with SignalR because its behavior can change a lot according to the chosen transport strategy. With WebSockets you might have several hub instantiations/method calls over the same connection, while with Long Polling you would probably have one (or zero) per HTTP request. Check here and here.
Given that the code you write with SignalR should be the same regardless of the transport, I think for hubs you'd always have to handle repositories in a specific way, maybe with an ad-hoc factory always clearing the cache each time a repository has to be supplied to a SignalR hub (you could try to be smart and check the transport strategy used, but those could be muddy waters).
I have an application architecture which has following layers (or c# projects).
web front end (asp.net mvc2)
service layer (normal c# class library)
Model layer (normal c# class library with entities, service and repository Interfaces)
Data layer (implements repository interface defined in BLL and uses NHibernate)
ISession is opened per http request and its working fine.
Now, I would like to add wcf layer on top of my current service layer. wcf project plainly calls original service layer classes. But as soon as I do this, the session/session factory at asp.net becomes unusable/unavailable. Looks like, wcf is running in totally different context than asp.net. Hence I would like to move the logic of initinializing session factory and session management to wcf. How should I do it? and even before is it a good practice? one of the reason I would like to add wcf is because I want to expose the operations to other applications (which may not be http based).
Any help, blog post or book reference would be greatly appreciated.
Use Per-call instancing of NHibernate session. Check this article. It explains how to create attribute which will attach Session to current instance context.
you probably want to have WCF running in the same context as asp.net... try this article:
http://msdn.microsoft.com/en-us/library/aa702682.aspx