I have my project design as below:
MVC 4 (presentation)(using ninject as DI)
WCF Service (BAL)
DAL library - (Core ADO.NET)
Common library (contain DTO and utility)
Now, I want to add - Exception management and Logging mechanism.
Can any one suggest how i could use enterprise library withing this ?
Additionally, it would be also find if any one can suggest validation mechanism to manage through enterprise library - client side and server side.
Enterprise library 5 - .NET framework 4.
Thank You
Sounds you like are looking for a logging solution like log4net or NLog? They are two of the most popular .NET logging frameworks. For exceptions you can also look at using ELMAH.
There are also commercial products that you can get to provide much more advanced functionality around exceptions and logs. Those products typically allow you to configure log4net or NLog to forward the data to them. Commercial products can aggregate all your logs together and give you alerts, dashboards, etc. Stackify is one product that can do both exceptions and logs together. There are also products that only do exceptions or logs like Airbrake or Papertrail.
Related
I am working with miniprofiler and find it very helpful.
I have an mvc4 application that gets its data from a set of wcf services over named pipes. I am in control of both the mvc4 app and the wcf services.
I was reading this post on how to profile the lower layers of the architecture, but maybe I missing something but could not find MvcMiniProfiler.WCF package or part of the MvcMiniProfiler package. Is this still available?
Another question I have is it possible to set up miniprofiler to log to file? I have automated performance tests that are ran against my application that I would like to record the profiling for to understand how the application behaves under load.
Im required to write a Silverlight application using WCF.
I'm also required to use Dependency Injection to gain access to this service in another library.
(I add a Silverlight enabled WCF Service)
The problem is in trying to use Dependency Injection (Prism/MEF in this case). When I make a Silverlight Shared library that will have interfaces for this service, I cannot add this library in the ASP.Net project due to the fact that it is Silverlight library. If I make a non-Silverlight library I cannot add that library to other projects to share that common interface.
Basically I need a library I think to share between projects in Silverlight so I can do this service injection.
Any information is appreciated
As slugster said - this done via linking to windows library files from silverlight library.
You do it as described here: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
I just wanted to add.. Since you go there - what you need is another Framework/Technology. Usually those classes you talking about depend on other classes/namespaces that live in windows only or silverlight only world. And then you need to transfer object data via wire.
Microsoft's solution to this - RIA Services. What it does - it takes your Windows classes and generates proxy classes on Silverlight side. Kind of what you need. And it works with WCF services.
There is 3rd party solutions like CSLA and DevForce.
I use DevForce and it does many things automatically, but instead of generating proxy classes - it creates links just like what you want.
Whether you realise it or not, your question is a duplicate of this one: Shared data object between WCF service and Silverlight app While not asked the same way, the answer is the same.
You need to create a separate project, and share the code files (as links) from one project to the other. Your problem is that the Silverlight project is compiled for a different runtime to the ASP.NET/WCF project. Because they cannot reference a common library, linking the shared files as mentioned is the easiest way to share code between the two projects targetting different runtimes.
I want to add non-silverlight assembly to a silverlight project,
is there any way to do this? or what will be the other option to do ?
As Andrey writes, it's impossible to add a non-Silverlight assembly to a Silverlight project. If you really need to use it, you have no option but to run it server-side. You may already have a Web project that goes with the Silverlight project, and if so, that's where you should add a reference to this assembly.
The technology used to make remote calls from Silverlight to the web project is WCF RIA Services. The page I linked to contains plenty of documentation and videos to help you learn about WCF RIA Services.
There are, however, a few situations in which this approach won't work. Perhaps none of them apply to your circumstances, but since you don't provide any details about this assembly, I can't be sure.
If, for example, your assembly contains some WPF controls and you want to add them to your Silverlight application, you're out of luck. You'll have to find Silverlight-specific equivalents.
If you'll be calling this assembly frequently, you might find your Silverlight application spending a lot of time waiting for the server to respond. This could slow your application down significantly.
If your application needs to be able to run out-of-the-browser and disconnected from the internet (a requirement of my current Silverlight project), you will also be out of luck.
There are a number of things that I can think of that should work reasonably well over WCF RIA Services:
sending email, calling web services or various other network-related activities,
talking to a database,
mathematical calculations.
It is impossible because Silverlight has different runtime from full .net framework. The common way to solve it is to create WCF service that will have access to that assembly and provide remote access for Silverlight application.
I've recently started learning the WCF Framework and I have an Active Directory Helper class/library that I've created to house my code for interacting with Active Directory. I'm not sure if I'm reinventing the wheel trying to do this but it seems like it'd be a better implementation to run this Active Directory Helper library as a WCF service within my network and reference that service from any internal application.
My question is, is this something that would be a worthwhile endeavor, is what I'm doing redundant, or is there something else better out there that would already do what I'm looking to implement?
I've found this article in a Google search on this topic:
http://blog.waleedmohamed.net/2009/12/create-active-directory-service-using.html
but it wasn't very intuitive for me to follow along and I don't like the idea of putting domain credentials for something in any config file. Other than that there doesn't seem to be a lot of information on the topic.
Update
The AD Helper library I've developed utilizes the System.DirectoryServices namespace and implements things like:
Instantiate users in ADAM: http://www.koders.com/csharp/fidCD7765F2E9C23683407CEFAFAFB68D3157857BFB.aspx?s=cdef:%22Adam%22#L18
Recursively get all users in a Security Group: http://www.volumeracing.com/blog/?p=129
etc...
My goal is to implement these things as a WCF service over NetTcp so instead of including this AD Helper dll in every project that would want to do these things as well, I can just have my projects call the WCF service. Then if I ever needed to add or update the AD Helper dll, I can do so without having to update all my projects that implement the AD Helper dll.
I would check out these things before proceeding:
What's New in AD DS: Active Directory Web Services
Active Directory Web Services Overview
Active Directory Gateway WebService is available for ‘legacy’ OSes
Introducing the New Active Directory Domain Services in Windows Server 2008 R2
There's a lot going on in this space - however, in most cases, it requires very recent server OS versions (Windows Server 2008 or 2008 R2).
I would take a good close look at these offerings from Microsoft, and then decide whether it's worth doing this on your own - or just use this instead.
A little background -- we're designing an application that uses a client/server architecture consisting of:
A server which loads server-side modules, potentially developed by other teams.
A client which loads corresponding client-side modules (also potentially developed by those other teams; each client module corresponds with a server module).
The client side communicates with the server side for general coordination, and as well as module specific tasks. (At this point, I think that means client talks to server, client modules talk to server modules.)
Environment is .NET 3.5, and client side is WPF.
The deployment scenario introduces the potential to upgrade the server, any server-side module, the client, and any client-side module independently. However, being able to "work" using mismatched versions is required. I'm therefore concerned about versioning issues.
My thinking so far:
A Windows Service for the server.
Using System.AddIn for the server to load and communicate with the server modules will give us the greatest flexibility in terms of version compatability between server and server modules.
The server and each server module vend WCF services for communication to the client side; communication between the server and a server module, or between two server modules use the AddIn contracts. (One advantage of this is that a module can expose a different interface within the server and outside it.)
Similarly, the client uses System.AddIn to find, load, and communicate with the client modules.
Client communications with client modules is via the AddIn interface; communications from the client and from client modules to the server side are via WCF.
For maximum resilience, each module will run in a separate app-domain.
In general, the system has modest performance requirements, so marshalling and crossing process boundaries is not expected to be a performance concern. (Performance requirement is basically summed up by: don't get in the way of the other parts of the system not described here.)
My questions are around the idea of having two different communication and versioning models to work with which will be an added burden on our developers. System.AddIn seems quite powerful, but also a little unwieldly. (I'm also unsure of Microsoft's commitment to it in the future.) On the other hand, I'm not thrilled with WCF's versioning capabilities. I have a feeling that it would be possible to implement the System.AddIn view/adapter/contract system within WCF, but being fairly new to both technologies, I would have no idea of where to start.
So... Am I on the right track here? Am I doing this the hard way? Are there gotchas I need to be aware of on this road?
Thanks.
This sounds too complicated. Consider an architecture where each added module includes both the client side code (use System.AddIn if you like), but where the server side module is a new service.svc file. The client would know the URL to the corresponding service.
Alternatively, you should look into Microsoft Extensibility Framework (MEF) for the add-in feature. That's what they'll be starting to use for Visual Studio extensibility in the coming release.