Under certain stress conditions (such as clients accessing SQL Server from the same computer), the SQL Server Shared Memory protocol may lower BizTalk Server performance. You can resolve this problem by disabling the use of the Shared Memory network protocol in the SQL Server Client Network Utility. To disable Shared Memory protocol for SQL Server […]
Windows SharePoint Services is a collection of services for Windows Server which enable you to share information, collaborate with other users on documents, and create lists and Web part pages. For information and procedures on installing Windows SharePoint Services, see Appendix A. Note You do not need to install WSS if you do not also […]
This is a pretty obscure one, and a nice short snippet of a blog post. I ran into this error yesterday while building out some StreamInsight applications for real time web analytics, and was very briefly stumped. Let’s have a quick peek at how I ran into it.
Starting with a working query, I needed a different pivot/aggregation on the same data stream. My working query was:
Pretty basic stuff – now, I wanted to group by another field (in this case a field called EdgeServerName). So, I copy and paste, change the grouping field name and away we go:
Should be fine – right? Those of you familiar with LINQ are probably already laughing at the minor syntax mistake I made, but for the rest of us here’s what happened when I tried to run the query:
Microsoft.ComplexEventProcessing.Linq.QueryGenerationException was unhandled Message=The field 'Key' of type 'IKey`1' either contains a nested member, or is a type that is not supported as event type field. Source=Microsoft.ComplexEventProcessing.Diagnostics StackTrace: Microsoft.ComplexEventProcessing.Diagnostics.Exceptions.Throw(Exception exception) at Microsoft.ComplexEventProcessing.Linq.GroupUnionSelectRewriter.VisitMemberAccess(MemberExpression memberExpr) ... |
Ouch. What did I do wrong? A composite group key must have more than one field!
| Right | Wrong! | Right |
|
Code Snippet
|
Code Snippet
|
Code Snippet
|
Removing the new {} syntax for a single grouping field worked perfectly. Another bit of LINQ learned!
But wait there’s more! Through the course of the same project, I also ran into another way to throw this error, in a slightly different fashion.
If you have a composite key, and don’t use the individual properties of the grouping key, the error is thrown. Easy in retrospect, right?
Duplicate Rows in a table can be very irritating and cause for many headaches. So how can you identify duplicate rows in a table? SQL Server provides no visual tool or a built in function to show you the duplicate rows in a table, so you need to write your own query to get the duplicate rows.
read more
If you are working with SQL Server and looking for a way to get the row count of all tables in your database, you can do that using this SQL Query.
This Query will display a list of all Tables in your database and a count of the number of Rows the table has.
read more
If you need to trace all the connections from Applications and other Clients to your SQL Database you can do so with the following queries.
read more
Today we are announcing the Windows Azure AppFabric CTP October Release, available in our LABS environment: http://portal.appfabriclabs.com.
This release introduces an exciting new service called Windows Azure AppFabric Caching, some important new features for Service Bus, and some bug fixes for Access Control. The Caching service is the first of several new services planned for AppFabric, several of which are being announced at PDC today.
Taken together these new services take Windows Azure AppFabric beyond the scope of providing cloud connectivity and start to fulfill the vision of a comprehensive cloud middleware platform for developing, deploying and managing applications on the Windows Azure Platform. You can learn more about Windows Azure AppFabric, including the new services announced today at PDC, on our new website – www.microsoft.com/appfabric/azure.
Here are the highlights of the release:
Caching: Windows Azure AppFabric Caching is a distributed, in-memory cache for applications running in Windows Azure.
Service Bus: In this release we are introducing some new enhancements to the Service Bus:
Note: this release of Service Bus is focused on getting feedback in these new features and does not support the full set of features available in production today. We will be adding all of the production features back together with the new features in a future CTP release in LABS before releasing the full updated Service Bus to production.
Access Control: This release contains only bug fixes for Access Control; no new functionality added since the LABS September Release.
Keep in mind that in the LABS environment there is no SLA, but accounts and usage of the services are free. As always, we encourage you to check it out and let us know what you think of the new features.
The Windows Azure AppFabric Team
Two weeks ago we shipped the ASP.NET MVC 3 Beta Release. It supports “go live” deployments, and includes a bunch of nice improvements/enhancements. You can see a summary of the new ASP.NET MVC 3 features in my beta announcement post. Also read my original ASP.NET MVC 3 Preview post to learn about other ASP.NET MVC 3 features that showed up with that initial preview release.
This is another in a series of “mini-posts” I’m doing that talk about a few of the new ASP.NET MVC 3 Beta features in more detail:
In today’s post I’m going to discuss layout pages with Razor, and discuss some of the improvements to them that we introduced with the recent ASP.NET MVC 3 Beta.
ASP.NET MVC 3 ships with a new view-engine option called “Razor” (in addition to continuing to support/enhance the existing .aspx view engine).
You can learn more about Razor, why we are introducing it, and the syntax it supports from my Introducing Razor blog post. If you haven’t read that post yet, take a few minutes and read it now (since the rest of this post will assume you have read it). Once you’ve read the Introducing Razor post, also read my ASP.NET MVC 3 Preview post and look over the ASP.NET MVC 3 Razor sample I included in it.
You typically want to maintain a consistent look and feel across all of the pages within your web-site/application. ASP.NET 2.0 introduced the concept of “master pages” which helps enable this when using .aspx based pages or templates. Razor also supports this concept with a feature called “layouts” – which allow you to define a common site template, and then inherit its look and feel across all the views/pages on your site.
In my last blog post I walked through a simple example of how to implement a /Products URL that renders a list of product categories:
![image_thumb_1263F129[1]](http://weblogs.asp.net/blogs/scottgu/image_thumb_1263F1291_1BDEFEE8.png "image_thumb_1263F129[1]")
Below is a simple ProductsController implementation that implements the /Products URL above. It retrieves a list of product categories from a database, and then passes them off to a view file to render an appropriate HTML response back to the browser:
![image_thumb_579C4852[1]](http://weblogs.asp.net/blogs/scottgu/image_thumb_579C48521_6A901487.png "image_thumb_579C4852[1]")
Here is what the Index.cshtml view file (implemented using Razor) looks like:
![image_thumb_17A2B20D[1]](http://weblogs.asp.net/blogs/scottgu/image_thumb_17A2B20D1_1B9F295B.png "image_thumb_17A2B20D[1]")
The above view file does not yet use a layout page – which means that as we add additional URLs and pages to the site we’ll end up duplicating our core site layout in multiple places. Using a layout will allow us to avoid this duplication and make it much easier to manage our site design going forward. Let’s update our sample to use one now.
Refactoring to use a Layout
Razor makes it really easy to start from an existing page and refactor it to use a layout. Let’s do that with our simple sample above. Our first step will be to add a “SiteLayout.cshtml” file to our project under the \Views\Shared folder of our project (which is the default place where common view files/templates go):
SiteLayout.cshtml
We’ll use the SiteLayout.cshtml file to define the common content of our site. Below is an example of what it might look like:
A couple of things to note with the above file:
And now we have a common layout template that we can use to maintain a consistent look and feel across any number of pages on our site.
Index.cshtml
Let’s now update our Index.cshtml view to be based on the SiteLayout.cshtml file we just created. Below is an first-cut of what it might look like:
A couple of things to note about the above file:
We did not need to wrap our main body content within a tag or element – by default Razor will automatically treat the content of Index.cshtml as the “body” section of the layout page. We can optionally define “named sections” if our layout has multiple replaceable regions. But Razor makes the 90% case (where you only have a body section) super clean and simple.
We are programmatically setting the View.Title value within our Index.cshtml page above. The code within our Index.cshtml file will run before the SiteLayout.cshtml code runs – and so we can write view code that programmatically sets values we want to pass to our layout to render. This is particularly useful for things like setting the page’s title, as well as <meta> elements within the <head> for search engine optimization (SEO).
At the moment, we are programmatically setting the Layout template to use within our Index.cshtml page. We can do this by setting the Layout property on the View (note: in the first preview this property was called “LayoutPage” – we changed it to just be “Layout” with the ASP.NET MVC 3 Beta). I’ll discuss some alternative ways (new with the ASP.NET MVC 3 Beta) that we can set this property shortly.
And now when we request the /Products URL within our site, we’ll get the following HTML returned:
Notice above how the returned HTML content is a merge of the SiteLayout.cshtmk and Index.cshtml. The “Product Categories” title at the top is set correctly based on the view, and our dynamic list of categories is populated in the correct place.
Currently we are programmatically setting the layout file to use at the top of our Index.cshtml file. This is fine for cases where we have some view-specific logic where the layout file will vary depending on the specific view. But setting it this way can end up being redundant and duplicative for most web applications – where either all of the views use the same layout, or if they have different layouts (for example: for mobile devices or localized sites) the logic for which layout to pick is common across all of the views.
The good news is that Razor (starting with the ASP.NET MVC 3 Beta release) includes a new feature that enables us to remove the need to explicitly set the Layout in each view – and instead allows us to define the layout logic once for all views in the site – making our view files even cleaner and more maintainable (and ensuring we keep to the DRY principle: Don’t Repeat Yourself):
Starting with the ASP.NET MVC 3 Beta release, you can now add a file called _ViewStart.cshtml (or _ViewStart.vbhtml for VB) underneath the \Views folder of your project:
The _ViewStart file can be used to define common view code that you want to execute at the start of each View’s rendering. For example, we could write code like below within our _ViewStart.cshtml file to programmatically set the Layout property for each View to be the SiteLayout.cshtml file by default:
Because this code executes at the start of each View, we no longer need to explicitly set the Layout in any of our individual view files (except if we wanted to override the default value above).
Important: Because the _ViewStart.cshtml allows us to write code, we can optionally make our Layout selection logic richer than just a basic property set. For example: we could vary the Layout template that we use depending on what type of device is accessing the site – and have a phone or tablet optimized layout for those devices, and a desktop optimized layout for PCs/Laptops. Or if we were building a CMS system or common shared app that is used across multiple customers we could select different layouts to use depending on the customer (or their role) when accessing the site.
This enables a lot of UI flexibility. It also allows you to more easily write view logic once, and avoid repeating it in multiple places.
Note: You can also specify layouts within a Controller or an Action Filter. So if you prefer to keep the layout selection logic there you can do that as well.
Below is a screen-shot of the simple application we have been building:
Here is the ProductsControllers that implements the /Products URL and retrieves the categories from a database and passes them to a view template to render:
Here is the Index.cshtml view that we are using the render the /Products response:
Here is the SiteLayout.cshtml layout file we are using to implement a consistent look and feel across our site:
Here is the _ViewStart.cshtml file that we are using to specify that all views in our site by default use the SiteLayout.cshtml file:
And here is the generated HTML from the /Products URL:
And because we now have a common layout file for our site, we can build out more functionality, controllers and views within our application – and have a site UI experience that is both consistent and very easy to maintain.
Two common questions people often ask are:
1) Can I have nested layout files?
2) Can I have multiple, non-contiguous, replaceable regions within a layout file – so that I can “fill in” multiple different sections within my view files.
The answer to both of these questions is YES! I’ll blog some samples of how to do this in the future.
As I’ve mentioned before, one of the themes we’ve focused on with the ASP.NET MVC 3 and Razor releases has been to make the code you write cleaner and more concise. We think the new layout functionality coming with this release contributes nicely towards making view files even easier to read and write. I’ll be covering other nice improvements like this that are new to the ASP.NET MVC 3 Beta in future posts.
Hope this helps,
Scott
P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu
The title lends itself to a bit thought. Why would the developer feel the need hold a static reference to the MetadataWorkspace of an Entity Framework (EF) model from within their WCF service-oriented applications? The premise being that the WCF services are using EF to serve up data from a backend data store. The answer is twofold. Firstly, loading the EF metadata data into memory is expensive and secondly and most importantly is that EF has a depreciation policy for the metadata cache. The deprecation policy kicks in after the predetermined threshold has been reach (typically 20 minutes of idle time) and removes the metadata from cache. This means that the expense of loading EF metadata into memory is incurred after the idle time has been reach and the deprecation policy has been completed. In laymen terms, the first WCF client call making use of an EF query is subject to a warm-up delay while EF loads the metadata cache. The larger the model, the longer that ‘first’ user of the service must wait for their results. To maintain consistent service response rates, one can hold a reference to the MetadataWorkspace object to ensure that EF doesn’t remove it from its cache.
In short, the solution submitted in this blog pertains to those applications exhibiting lengthy EF startup durations, periodic idle time with their services and a client base that expects predictable service response times.
When an EntityConnection is created, the Entity Framework will load the conceptual, storage and mapping between the conceptual model and the storage model. You can see this if you examine the CSpace (conceptual), SSpace (storage), and CSSpace (conceptual/storage mapping) item collection properties of the MetadataCache instance once the EDM has been loaded. For example, the following code opens an EntityConnection and a QuickWatch of the MetadataWorkspace property of the connection reveals the CSpace, CSSpace, OCSpace, OSpace and SSpace collection properties. With this model we have 274 items in the conceptual model, 314 items in the storage model and 1 item in the conceptual to storage mapping.
Note: the model was created from the AdventureWorksLT2008R2 which is included with the SQL Server 2008R2 product sample databases on codeplex.
CSpace 274
OSpace 0
SSpace 314
CSSpace 1
OCSpace 0
So how do we load the object model? The MetadataWorkspace object constructor sound promising. It can load all the .csdl, .msl and ssdl embedded resources from the available assemblies. Let’s give it a try. The following code assumes that model resources are embedded into the executing assembly. If not, the assembly fully qualified name would have to be used together with a known type to return the assembly for the model. An example of which is commented out in the code snippet below. If your model is created in a separate assembly, then you must load the assembly using the assembly qualified name of a type within the model as shown in the lines 1-4 in the code snippet below.
CSpace 274
OSpace 0
SSpace 314
CSSpace 1
OCSpace 0
As we can see from the output above, the object model is not loaded. This is because the object model is loaded during view generation or during the first query referencing an entity set. The generated views are then stored inside the object model. So what this means is that we can load the conceptual, storage and conceptual to storage mapping into a MetadataWorkspace instance and then instantiate a new EntityConnection using this MetadataWorkspace instance. The EntityConnection instance can then be used to in the ObjectContext constructor. The only thing left would be to build a LINQ query which becomes converted into a command tree upon which the object model is loaded into cache. A code sample is shown below.
CSpace 274
OSpace 39
SSpace 314
CSSpace 1
OCSpace 37
What’s left is to initialize the EF MetadataWorkspace during startup of the WCF service and hold a static reference which can be used for subsequent EF queries. Fortunately WCF offers a number of trivial options to perform ‘hook’ into the service startup. Below is a list of a number of options, you can read this blog entry for a more descriptive read. I will show a straight forward sample of initializing the MetadataWorkspace by creating custom ServiceHostFactory and ServiceHost classes and implementing the ServiceHostBase.InitializeRunTime() method.
Create a class to hold a global static reference to the MetadataWorkspace which can be globally referenced.
Create a WCF Service called AWSales. Modify the interface to include a operational contract, for example GetCustomers(string firstName).
Create a custom service host by deriving from ServiceHost.
Create a custom ServiceHostFactory to instantiate the derived ServiceHost.
Implement the service contract and utilize the static reference to MetadataWorkspace when creating your EntityConnections.
Set the ‘Factory’ attribute in the .svc file.
The practice suggested in this blog does not pertain to all WCF services. For those smaller or medium size EF models it doesn’t really matter if the Entity Framework deprecates the metadata cache after periods of inactivity, the model will load quite quickly and in the end, the user will never know this occurred. But for larger models, where loading time is much longer and the experience of the end user could be impacted, the technique outlined in this blog may be worth exploring.
So what happens when you create a few operations or services during a single instance of the BizTalk WCF Service Publishing wizard? What types of web service projects and BizTalk messaging configurations get produced? I was messing around with this the other day, and thought I’d quickly show the output. Maybe this is common knowledge, […]