MvvmLight dynamic message token - mvvm-light

Is it possible to send register for a Message that is created with a dynamic token?
I have several user controls that are in a ItemsControl and I want each control to only listen for messages that target a certain Id.
Keeps throwing a un-handled exception.

Please see the video of Laurent Bugnion, who has developed the mvvm-light toolkit:
http://channel9.msdn.com/Events/MIX/MIX11/OPN03
He is saying about a universal lambda converter in this discussion.

Related

Generic Exception Handler Orchestration in BizTalk

Hi All BizTalk Developers,
I need some input and guidance on how to design an Orchestration that can take few parameters as Input and log them in SQL server table (tblTrackingData)
I want to start this orchestration at various points, for example when I am calling a webservice so I want to log the request in DB and when I get the response then I want to log the response xml also in the same table.
In case of any exception I want to log error message and other details in the same table for tracking purpose.
Can some one guide me, direct me to some existing blogs/posts on how to handle this generic tracking / exceptions etc by starting a new Orchestration.
The purpose of a new Orchestration is to call it from anywhere, please suggest if it could be handled in a better way also.
Thanks.
The best advice, don't do this.
The reason? Everything you describe is already done by BizTalk Server automatically by BizTalk Tracking and the Event Log.
I can tell you from experience, you will not need anything else beyond Tracking and the Event Log.
I do recommend you implement proper exception handling within you app and log custom events, but they would also be written to a Windows Event Log only as well.

Do you do client-side logging?

How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.

ASP.NET logging Events in DB

Can ASP.NET's System.web.Management be used for logging events like user logins, password changes and access to certain resources? Should system.Web.Management be used for logging of errors and health monitoring instead?
I want to log events without re-inventing the whole thing. I know ELMAH is used for errors; can it be used for logging events too?
From the article ELMAH - Error Logging Modules And Handlers on the now defunct DoNetSlackers:
Error signaling is exposed via the ErrorSignal class, which provides a single overloaded method called Raise. Simply put, exceptions raised via the ErrorSignal class are not thrown, therefore they don't bubble up, but instead are only sent out to ELMAH, as well as to whomever subscribes to the Raise event of the ErrorSignal class.
The code snippet below shows how to obtain an instance of the ErrorSignal class, which is unique per application and can be retrieved simply with the static FromCurrentContext method, and then use it to signal an exception.
ErrorSignal.FromCurrentContext().Raise(new NotSupportedException());
The difference between signaling and throwing an exception is that in the first case no one will ever know about the error except ELMAH.
Further Reading:
How to get ELMAH to work with ASP.NET MVC [HandleError] attribute?

Creating a custom SOAP adapter for BizTalk ESB Toolkit 2.0

Using the BizTalk ESB Toolkit 2.0
We are working on a project where we need to call a proxy to a web service which is a DLL. We have no problems doing this via an orchestration since you can use a static port and configure it to use the SOAP adapter with the web service setting pointing at the assembly in the BizTalk Admin interface. In the itinerary though there doesn't seem to be an obvious way to do this since dynamic ports don't have the option to use the SOAP adapter.
There is a good reason why we want to do this, don't worry.
Following on from this, we implemented a custom adaptor provider but are having problems getting it to work.
We followed an (old) example shown here:
The custom adaptor provider inherits from BaseAdapterProvider and overrides the SetEndPoint(Dictionary, IBaseMessageContext) method.
The method extracts the assembly name, type name, and method name that are passed in via the resolver dictionary and then writes them to the pipeline context:
pipelineContext.Write("TypeName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);
and sets the transport type to soap:
pipelineContext.Write("TransportType",
"http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");
In all other respects the adapter provider is nearly identical to the example shown in the link above, except for the obvious change from SMTP to SOAP.
The adapter provider assembly is signed, GACed, and added to the esb.config.
The adapter provider is called from an itinerary that only calls the service and then returns the response. We are testing the itinerary from the Itinerary Test Client that is shipped with the toolkit. Event logging within the custom adapter shows that the adapter code is being called. The problem is that the message is not being routed to the service proxy. The event viewer gives the following error:
The Messaging engine failed to process
a message submitted by adapter:SOAP
Source
URL:/ESB.ItineraryServices.Response/ProcessItinerary.asmx.
Details:The published message could
not be routed because no subscribers
were found. This error occurs if the
subscribing orchestration or send port
has not been enlisted, or if some of
the message properties necessary for
subscription evaluation have not been
promoted. Please use the Biztalk
Administration console to troubleshoot
this failure.
Investigating the suspended service instamces in Group Overview shows two things:
The values for assembly name, type name, and method name are being set correctly.
The message body is missing.
We have tried configuring the send and receive pipelines on the send port to be both XMLTransmit/XMLReceive and ItinerarySendPassthrough/PassthroughReceive and it makes no difference.
Is there something obvious we might have missed? Do you have to explicitly pass the message body through? If so how?
EDIT:
Following a request from the BizTalk ESB Toolkit forum I am posting screen shots of the itinerary, context and send port filters.
Itinerary,
Context,
Port filters.
Many thanks, Nigel.
first of all I'll say you are trying to over engineer the solution. Adapter development is not trivial and there are various things you need to take in to consideration. Developing and Deploying adapters are categorized as platform changes, which effects your whole environment, so if you are not familiar then your shouldn't do it. I would recommend you taking some other route. At this point I personally don't have enough insight into ESB internals, so won't be able to comment on it. At worst case you may be better off using the .NET proxy dll directly inside your orchestration (expression or message shape) rather than building an adapter. Even though its not recommended approach, still I feel its better than custom adapter approach.
Semantically, I don't see why a solution that involves a WCF-BasicHtpp adapter would not work in your scenario. In any case, I would definitely try to see what happens with a WCF-BasicHttp adapter, and once I got a working solution, I would switch to a custom SOAP adapter if that is really necessary.
Currently, your solution is weird - in the sense that you have an On-Ramp directly connected to an Off-Ramp. I've never seen that in any of my itineraries. You might need to create an intermediate messaging or orchestration Itinerary service in betweeen.
Otherwise, the message effectively gets published to the message box and obviously there is no subscribers for it, hence the error you encounter.

Extend the exception thrown from ASP.NET when calling a Webservice from JQuery

I'm using JQuery to load controls dynamically in an ASP.NET development environment using JSON and WebServices. Within this solution I have a business logic layer which has a built in validation mechanism (i.e. validating properties and business rules similar to that of CSLA)
When requesting a new control to be loaded dynamically using JQuery and an ASP.NET WebService, I would like to validate the input from the current control against the business logic validation mechanism (i.e. server side validation) and notify the user if there was any problems.
I managed to achieve this, however, when validation fails in the web service I would like to throw a customer exception containing the validation field id's and associated error messages.
In JQuery, I test for this specific ExceptionType and would like to apply the error messages dynamically to the controls listed in the exception type properties. This is where my problem comes in. Even though I created a custom exception with custom properties the exception that is passed to JQuery in JSON format from the WebService is still a standard exception with none of the additional properties listed. I could simply create a JSON formatted string of values in the exception's message property but would ultimately prefer something a little more elegant. Does anyone know how you can override the serialized exception created by ASP.NET for situations such as this...
Thank you in advance...
G
I ran into something very similar a couple days ago - basically there's no way to make ASP.NET generate custom exceptions. This is by design, since returning a specific type of exceptions would
[...] expose implementation
details/bugs to the clients. We could
do something with special exception
type that we let pass through, but its
too late for this release [...]
You could always return different HTTP status codes, and have the browser handle them as custom exceptions - for example, a 500 error would mean one thing, a 401 something else, etc. I think the best solution is to make your method return a string with the exception stack - not elegant, but at least this way the client has all the exception details.
Dave Ward also has info on ASP.NET AJAX service errors.

Resources