WebCast MSDN: Introducción a Páginas Web con ASP.NET y Razor Syntax
Hope to have you with us in this event (next 20th March). Register here.
Sharing my daily work experience..
Hope to have you with us in this event (next 20th March). Register here.
Published By
Javier Arguello
at
12:35 AM
0
comments
This is an experiment to caché results from static classes in an ASP.NET MVC project.
Domain services (see DDD) are static classes for this project :(.
Caché usage is as following:
The MethodCache.Get uses the calling method name as caché Key (in the previous code fragment TiposMoneda), so you don’t need to specify a caché key if you don’t want to.
Here is my implementation:
Note the NoInlining method option. This is a very important flag to the CLR. We don’t want to inline the method as it would interfere with the StackTrace (thus with the evaluation of the caché key).
Published By
Javier Arguello
at
1:06 AM
0
comments
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” Martin Fowler
Using Code Metrics feature of Visual Studio (or Code Metrics Power Tools if you don’t have Premium or Ultimate edition) you can get some good information about which unit of code or components are candidates for refactoring.
Use this tool regularly in order to track refactoring opportunities. Check this MSDN article and this Post for usage.
Some metric hints you could use:
For valid ranges, check this Post.
PS: I will be working on how to get this metrics into a TFS Team Project Report.
Published By
Javier Arguello
at
1:07 AM
0
comments
Labels: ALM, Code Metrics, Team Foundation Server, Team System, Visual Studio
A good Agile practice that I’ve personally tested is registering our daily work evidence using images. Source code images, screen images of our application, database tables, etc. Anything that could give other people a quick hint about our work.
Using TFS we can update daily Task status using Work Items. Having images associated and displayed with them is not as straight forward as it should be (like pasting images in Word or in an Email).
One recommended approach is to upload a very simple and lightweight PPT or Word document containing images of evidence for all team members to a folder in the project’s SharePoint site. This could be done under a folder called “Daily Evidence” or something. The name of the PPT/Word file could be the current date (02/23/2012) or such.
At the end of the day, a simple report could detail the status of tasks for every team member and have a link (calculated automatically) to the Evidence file in the SharePoint site.
End of Day Progress Report Sample
Using Reporting Services Subscriptions feature, you could also have this report sent by email automatically.
Published By
Javier Arguello
at
11:52 PM
0
comments
Labels: ALM, Team Foundation Server, Team System, TFS, Visual Studio
Hope to see you there next Tuesday (28th). Register here https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032506180&culture=en-us.
Published By
Javier Arguello
at
11:24 PM
0
comments
UI automation could be a very very complex procedure. Several things could change between different executions, controls could be moved or renamed, etc.
Some simple things such as closing a dialog popup/window could be challenging..
Let’s try to recreate the problem. File/New Project in Visual Studio 2010, then select Windows Forms.
Add a button with the following handler on the click event:
Record a CodedUI test that opens our super simple WinForm App, click Button1 and then close the message box. Finally, add one last step to record that closes the Main Window.
Now run the previous CodeUI test and check how the test reports a successful execution. Note that your Message Box is still opened and your application is still waiting for input.
* I imagine that it should be a better way of working around this effect than the following. If you figure it out let me know :).
Let’s create a UIMapExtensions class (containing extensions methods of course)
I am using 3 techniques in the previous code fragment. In each one of them, we wait for the control to respond to the close action (for 3000 ms).
Now you can just replace some of generated test code in the Test Class (not in the UIMap):
My two cents..
Published By
Javier Arguello
at
12:05 AM
0
comments
Labels: ALM, Testing, Visual Studio
Automatic Builds for Application Release is a current practice in every major development factory nowadays.
Using Team Foundation Server Build 2010 to accomplish this offers many opportunities to improve quality of your releases.
The following approach allow us to generate build drop folders including the BuildNumber and the Changeset or Label provided. Using this procedure we can quickly identify the generated binaries in the Drop Server with the corresponding Version.
BuildDetail.DropLocationRoot + "\" + BuildDetail.BuildDefinition.Name + "\" + If(String.IsNullOrWhiteSpace(GetVersion), BuildDetail.SourceGetVersion, GetVersion) + "_" + BuildDetail.BuildNumber
The previous expression sets the DropLocation with the following format: (ChangesetNumber|LabelName)_BuildName_BuildNumber
The first part of the folder name will be the changeset number or the label name (if triggered using labels). Folder names will be generated as following:
Try launching a build from a Changeset and from a Label. You can specify a Label in the GetVersion parameter in the Queue new Build Wizard, going to the Parameters tab (for labels add the “L” prefix):
Published By
Javier Arguello
at
9:36 PM
0
comments
Labels: Build, Team Foundation Server, Team System, TFS, Visual Studio
El próximo 29 de noviembre voy a participar como orador en Microsoft en este evento gratuito sobre Herramientas de desarrollo y patrones de Arquitectura. Vamos a tomar varios temas interesantes sobre Arquitectura y construcción de Frameworks de Desarrollo.
Si están interesados en asistir, se pueden comunicar conmigo a través de un comentario en este blog.
English: Next November 29th I will be participating as a speaker in a free admission event at Microsoft México offices. We will be discussing very interesting topics about Architecture and the development of Technical Frameworks.
Published By
Javier Arguello
at
8:31 PM
0
comments
Tomorrow I will be presenting “Load Test in Windows Azure with Visual Studio Test Agents” on MSDN. Hope to see you there.
Register here.
Published By
Javier Arguello
at
10:12 PM
0
comments
Labels: ALM, Azure, Testing, Visual Studio
As several people have found, Moles does not work well with DLR. Check Cameron’s post for this issue.
In order to make it work do the following:
I haven’t done further testing on changing the use of legacy CAS Policy when using Moles & VS Test Framework.
Let me know how it works for you.
Published By
Javier Arguello
at
6:45 PM
0
comments
In recent years there’s been major investments in developing tools in order to provide good quality assurance features and incorporate industry practices into them.
TDD, DDD, Unit Testing, Continuous Integration, etc.
Microsoft has recently (not so recently actually :)) ship some very nice features to help us improve our code quality by allowing us to create better tests over units of code.
Unit testing is all about proving individual units of code (positive and negative testing). Since a great deal of software is not always designed with this “unit independence” in mind, it can be a challenge to isolate dependencies for every piece of source code (specially legacy code).
Moles is an Isolation Framework that mocks/emulates the behavior of our components and external libraries, even for private members. You could even mock how a particular System.* class object in .NET behaves (check Pex & Moles site in Microsoft Research).
The following is a Repository object that uses Linq to Sql Data Context internally and doesn't provide a simple way of decoupling database access from its behavior. It means we cannot unit test the following class without a SQL database.
By using Moles, we could replace inner behavior of this class.
Note: This is White Box Testing, meaning you need to have access to internal implementation in order to know how to mock it.
Mocking with Moles
Download and install Moles.
Check this tutorial about Pex & Moles for more information about the previous steps.
The following code fragment unit test our GetCustomers method:
Check out the use of Moles to specify the behavior of enumeration for the Table<Customer> (Customers) that Linq to Sql Provider uses to execute the query in the database. In the previous code, we avoid querying data from database and return an in-memory list of customers.
When executing a lambda expression using Linq to Sql, the source Linq provider must interpret the query and then issue a command to the database.
In order to intercept the query and return mock results, we must override default behavior for the expression evaluation logic of the Linq Provider.
The previous mocking code returns a Mock QueryProvider that does not evaluate the expression, it simply returns the in-memory customer reference.
I encourage you that read more about Moles here.
PS: This cool framework intercepts any managed operation by creating a CLR Host for the application.
Published By
Javier Arguello
at
12:22 PM
0
comments
Labels: Moles, Testing, Unit Test, Visual Studio
If you haven´t installed Visual Studio 2010 SP1 yet and you’ve enabled automatic Windows Update, chances are you end up getting the following error when starting VS2010: Exception has been thrown by the target of an invocation.
There is a .NET 4 Framework in Windows update distributed recently that generates this conflict.
Solution: Install VS2010 Sp1.
Published By
Javier Arguello
at
10:50 AM
0
comments
Labels: Visual Studio
Next Wednesday (April 27th) I will presenting Parallel LINQ and showing some not trivial stuff to optimize performance in parallel algorithms. Register here.
Published By
Javier Arguello
at
12:52 AM
0
comments
Labels: C#, PLINQ, Visual Studio
I will be participating as an invited speaker in “Comunidad.NET” in Mexico City next Tuesday (April 26th). My presentation will be focusing code quality using Visual Studio Tools.
Agenda:
You can get more info from Raul’s blog.
Published By
Javier Arguello
at
12:30 AM
0
comments
Labels: ALM, Visual Studio
Sometime ago I published a way to use WCF service with the new Async Pattern in C#. The problem is that this approach won’t work with Silverlight. More specifically, TaskFactory is not available in Silverlight.
So.. here is one solution (it does not provide full functionality as in TaskFactory, but you can manage 90% of use cases):
The previous code fragment defines a helper method that behaves similar to TaskFactory.
Usage example:
And here is the service extension for MyServiceClient (Note that I use the service interface contract instead of the ClientBase<> as parameter since we need access to Begin/End methods):
Try it and let me know if it works for you..
Published By
Javier Arguello
at
11:30 PM
0
comments
Labels: Async, C#, Languages, Silverlight, Visual Studio
We are looking for smart and young .NET software developers, passionate about technology for our Mexico City office. If your are interested send us an email with your CV to rrhh@lagash.com specifying you are interested in Mexico City positions.
Thanks!
Published By
Javier Arguello
at
6:27 PM
0
comments
Labels: Offtopic
Some time ago I presented a simple way to version TFS Web Services in order to intercept and perform server side validations.
In this post I will introduce another way of doing so.
Check out the (poor documented) ITeamFoundationRequestFilter interface in MSDN. This interface is part of an extensibility method called TFS Filters.
Using this interface as a regular TFS plug-in (meaning you deploy it in the plugins directory as you do with subscribers) you can inspect method executions, requests, etc.
It is very useful when you need to create an audit log, measure performance (recording execution time or calls), diagnose connection problems, etc. In fact, when you connect to TFS from a version of Visual Studio lower than 2010, an implementation of this filter (check the Microsoft.TeamFoundation.ApplicationTier.PlugIns.Core.UserAgentCheckingFilter) throws an exception indicating that you need a patch for doing so.
The latter is the functionality I am personally more interested in: validations.
The interface defines the following methods in order to handle a request life cycle (in chronological order):
Sample debugging session (method information available when EnterMethod is executed):
Turns out that you can only abort the execution of the current request in the BeginRequest and RequestReady methods:
Note: As in my previous post, the next code sample is only meant to be an experiment in any case :).
By doing some ASP.NET HttRequest manipulation thought, you can implement a validation filter in the RequestReady or BeginRequest methods.
So… as I already made it clear, consider other alternatives before using this as production code.
The above sample code validates inputs in the BeginRequest method (you can always move it to the RequestReady). The TfsPackageValidator class inspects the current ASP.NET request and deserializes the input parameters. If it finds an Update operation over a Work Item (by looking at the SOAP Message Body), it continues with the validation process. What we are looking for here, is the Package element with the update information about the work item.
And here is my TfsPackageValidator class:
Try running this code when saving a Work Item with a priority field (by editing a single Work Item. If you edit the work item in a query view, the message passed to the server would be slightly different). You should see something similar to the following message in the client application:
The exception message is displayed in the dialog box (as a Technical information for administrator).
Download the sample code.
Published By
Javier Arguello
at
1:55 AM
0
comments
Labels: ALM, Team Foundation Server, Team System, TFS, Visual Studio
I will participating in a new Screencast tomorrow about new Azure features requested by the community. Admin mode and VM Role.
Click here to join.
Published By
Javier Arguello
at
12:34 AM
0
comments
Labels: Azure, Visual Studio
Check out this (very simple) code examples for TPL Dataflow.
Suppose you are developing an Async Logger to register application events to different sinks or log writers.
The logger architecture would be as follow:
Note how blocks can be composed to achieved desired behavior. The BufferBlock<T> is the pool of log entries to be process whereas linked ActionBlock<TInput> represent the log writers or sinks.
The previous composition would allows only one ActionBlock to consume entries at a time.
Implementation code would be something similar to (add reference to System.Threading.Tasks.Dataflow.dll in %User Documents%\Microsoft Visual Studio Async CTP\Documentation):
Note the filter applied to each link (in this case, the Logging Level selects the writer used). We can specify message filters using Predicate functions on each link.
Now, the previous sample is useless for a Logger since Logging Level is not exclusive (thus, several writers could be used to process a single message).
Let´s use a Broadcast<T> buffer instead of a BufferBlock<T>.
As this block copies the message to all its outputs, we need to define the copy function in the block constructor. In this case we create a new Tuple, but you can always use the Identity function if passing the same reference to every output.
Try both scenarios and compare the results.
Published By
Javier Arguello
at
3:26 AM
0
comments
Labels: Async, C#, Languages, Visual Studio
This article is a continuation of the series of asynchronous features included in the new Async CTP preview for next versions of C# and VB. Check out Part I for more information.
So, let’s continue with TPL Dataflow:
Definition (by quote of Async CTP doc): “TPL Dataflow (TDF) is a new .NET library for building concurrent applications. It promotes actor/agent-oriented designs through primitives for in-process message passing, dataflow, and pipelining. TDF builds upon the APIs and scheduling infrastructure provided by the Task Parallel Library (TPL) in .NET 4, and integrates with the language support for asynchrony provided by C#, Visual Basic, and F#.”
This means: data manipulation processed asynchronously.
“TPL Dataflow is focused on providing building blocks for message passing and parallelizing CPU- and I/O-intensive applications”.
Data manipulation is another hot area when designing asynchronous and parallel applications: how do you sync data access in a parallel environment? how do you avoid concurrency issues? how do you notify when data is available? how do you control how much data is waiting to be consumed? etc.
TDF provides data and action processing blocks. Imagine having preconfigured data processing pipelines to choose from, depending on the type of behavior you want. The most basic block is the BufferBlock<T>, which provides an storage for some kind of data (instances of <T>).
So, let’s review data processing blocks available. Blocks a categorized into three groups:
Think of them as electronic circuitry components :)..
1. BufferBlock<T>: it is a FIFO (First in First Out) queue. You can Post data to it and then Receive it synchronously or asynchronously. It synchronizes data consumption for only one receiver at a time (you can have many receivers but only one will actually process it).
2. BroadcastBlock<T>: same FIFO queue for messages (instances of <T>) but link the receiving event to all consumers (it makes the data available for consumption to N number of consumers). The developer can provide a function to make a copy of the data if necessary.
3. WriteOnceBlock<T>: it stores only one value and once it’s been set, it can never be replaced or overwritten again (immutable after being set). As with BroadcastBlock<T>, all consumers can obtain a copy of the value.
4. ActionBlock<TInput>: this executor block allows us to define an operation to be executed when posting data to the queue. Thus, we must pass in a delegate/lambda when creating the block. Posting data will result in an execution of the delegate for each data in the queue.
You could also specify how many parallel executions to allow (degree of parallelism).
5. TransformBlock<TInput, TOutput>: this is an executor block designed to transform each input, that is way it defines an output parameter. It ensures messages are processed and delivered in order.
6. TransformManyBlock<TInput, TOutput>: similar to TransformBlock but produces one or more outputs from each input.
7. BatchBlock<T>: combines N single items into one batch item (it buffers and batches inputs).
8. JoinBlock<T1, T2, …>: it generates tuples from all inputs (it aggregates inputs). Inputs could be of any type you want (T1, T2, etc.).
9. BatchJoinBlock<T1, T2, …>: aggregates tuples of collections. It generates collections for each type of input and then creates a tuple to contain each collection (Tuple<IList<T1>, IList<T2>>).
Next time I will show some examples of usage for each TDF block.
* Images taken from Microsoft’s Async CTP documentation.
Published By
Javier Arguello
at
2:50 AM
0
comments
Labels: Async, C#, Languages, Visual Studio