Left Outer Join using LINQ

Left outer joins are another example of something that's seems intuitive in SQL but appears foreign in LINQ.  Here we have two tables, TableOne and TableTwo both with a common TableOneId column.  TableOne always has a record and TableTwo has 0 to many records for each TableOne record.  The first query will return every record from both tables even if the TableOne record has no TableTwo record.  The second query will only return records from TableOne only if they have no corresponding TableTwo record.  By the way, this is VB.

'Without a where clause

Dim Query = 
    From t1 In TableOnes
    Group Join t2 In TableTwos On t1.TableOneId Equals t2.TableOneId Into gj = Group
    From grouping In gj.DefaultIfEmpty
    Select t1, grouping


'With a where clause

Dim Query = 
    From t1 In TableOnes
    Group Join t2 In TableTwos On t1.RecordId Equals t2.RecordId Into gj = Group
    From grouping In gj.DefaultIfEmpty
    Where grouping Is Nothing
    Select t1, grouping
 

Security Auditing in WCF

It is possible to log all security successes and/or failures to the event log by just modifying your configuration file.  This can be a quick and easy way to see if any funny business is going on with your web service.  However, a better solution is to log these types of events to a database that is easier to check and query on if you're doing this on a regular basis.

I'm a fan of the Service Configuration Editor tool (In Visual Studio, right click the web.config and select Edit WCF Configuration) rather than changing the XML directly, but it's helpful to see both.

First add a Service Behavior Configuration.  It doesn't necessarily have to be named.  Then add the serviceSecurityAudit behavior to the configuration:

Now, expand the behavior configuration, and select the newly added serviceSecurityAudit:

I recommend choosing the "Application" log as the location.  Here, I have chosen to log both successes and failures at the message level.  Once this is set up, simply go to the Event Viewer and you'll see information entries for each authentication or rejection.  To turn it off, just set it to None and leave it in the web.config in case you want to turn it on again.

Here is the settings as they exist in the XML:

<behaviors>
  <servicebehaviors>
    <behavior name="">

...

      <servicesecurityaudit auditloglocation="Application" 
          messageauthenticationauditlevel="SuccessOrFailure" 
          serviceauthorizationauditlevel="None">
      </servicesecurityaudit>
    </behavior>
  </servicebehaviors>
</behaviors>

Query XML files with LINQ

If you regularly work with XML, knowing a technique to directly query it can be a real asset.  I have found LINQ to XML together with LINQPad to be really helpful.  The best thing to do is to simply show an example.  Here we have a trivial XML file that we load in and display:

Then, let's say we want to list all plants from the file:

The tricky part is that if there are namespaces in your xml (and there usually is), then you need to include the namepace in braces.

Manually perform GET and POST HTTP actions

In an earlier post, I talked about HTTP and how to use the TELNET client to manually perform HTTP requests independent of a browser.  TELNET works great when playing around with requests on your local PC, but gets finicky when trying to connect to remote servers.  Plus, it's just plain tedious to work with.

I found that a better alternative is to write a little program to make these requests and then output the response to a text file.  It's actually pretty simple to do this in .NET by using the WebRequest class.  Here is a link to where you can find everything you need to know about WebRequest.

Simple .NET Web.Config Transform Files

Let's say you have a web application, and you're ready to publish the changes either to test or production.  After you get the files published to the web server, you have to go into the web.config file and change the settings so that it points to the proper environment (database connection strings, web service URLs, etc.).  Most times you remember to do this, but sometimes you don't.  Or maybe you have somebody else do it, and they forget.  Or sometimes the web.config gets deleted from the web server, and you have to guess what all the settings were.  This is where a transformation file can really help.

Visual Studio automatically generates a transform file for both the release and debug configurations.  You can see these by clicking "Show All Files" and expanding the web.config.  The transform file is just a set of rules telling the publish profile how to change the web.config for that configuration.  A simple example is below:

  
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.serviceModel>
    <client>
      <endpoint name="TheWebServiceName" address="http://www.thisisfake.com/FictionalService.svc" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" ></endpoint>
    </client>
  </system.serviceModel>
</configuration>

Our web application calls a web service that is at a different URL in production than in our development environment.  Above is a simple example of a transform file that changes the address attribute of the endpoint element when the name matches "TheWebServiceName".

Visual Studio Git

Visual Studio provides Git tools and will automatically detect the presence of a local Git repository even if you have set it up using command line tools.  I suggest continuing to use the command line tools if you are comfortable with that.  It can be confusing when you start editing a file that you are tracking with Git.  All of a sudden there is a check mark next to the file in Solution Explorer.  What just happened?  The answer is nothing.  Visual Studio can compare the file with the most recent commit in the repository and it is just letting you know that the file has changed.  If you were to click the Commit button in Team Explorer (remember, I prefer the command line tools), Visual Studio would first stage the files (git add) and immediately commit (git commit) them.

Git Overview

Git is an open-source software version control system.

It is a decentralized system which means that the source code repository resides on your local machine.  You make your changes on your local PC, you commit those changes to a repository on your local PC.

You can create a remote repository on GitHub or Assembla and "push" your changes to those sites in order for your teammates to download and "clone" their own local repository.

You can download Git here:  http://www.git-scm.com  This download includes a couple of GUI tools and Git Bash.

Git is a Unix program.  Although many GUI's exist for using Git, it is recommended that you learn to interact with the original program using a command line.  If you are using Windows, Git Bash is the program that you will use to give these commands to Git.

First configure Git:

git config --global user.name "Steve Emrick"
git config --global user.email steve@steve.com

You need to create a local repository.  Navigate to the directory that contains the folder to store your repository files. Then run an init command.

cd c:\users\semrick
git init <nameofsubdirectory>

To do anything with a repository you have to change the current directory to the directory containing the repository files.

If you change a file in your repository, and you want to commit the change, you have to "stage" the file by adding the file to the "index":

git add <Name of File>

Or, if you have a bunch of files in your repository, and you change a handful, you don't have to add each file individually.  Using the following command will add and only add the files you have changed from what is in the last commit:

git add .

Add on the dry-run option if you just want to see which files will be added:

git add . --dry-run

Perhaps, you want to see which files you have changed, but not staged:

git status

To commit a file in the index:

git commit --message 'A comment'

At this point, you will probably want to create what is called a "remote repository" hosted on the internet. After signing up on Assembla.com and creating a repository there, follow the instructions that Assembla provides.  If you use the https method, you just use the command below. Otherwise if you choose (ssh), you'll probably have to generate a certificate and register it with Assembla and Git.

git remote add origin https://git.assembla.com/{repository name goes here}.git

This creates a remote repository named origin on Assembla.  To "push" a commit to the remote repository just:

git push origin master

To "pull" commits down from the remote repository, just:

git pull origin master

If you make a change to a file, and before you add it to the index and commit it, you decide to undo it, you would:

git checkout <FilenameWithRelativePath>

I believe this replaces the specified file with the version from the most recent commit.  Checkout has a different meaning in Git than in TFS.  An easy way to find the path and all files that have been changed is to do a git status.