TDI Limited - possible scam

A friend of mine was contacted by someone claiming to be from a company called TDI Limited. The job involves: "Transferring payments straight from customers to our free-lancers by means of international money transfer systems"

It seems like a scam to me. I'm just putting this out there to see if anyone else hits this page looking for similar info.

Please leave a comment if you are getting something similar.

UPDATE: So, this is a scam. It is called a payment processing scam. See here for more details: http://www.delphifaq.com/faq/scams/f1057.shtml

Basically, they will have you set up a bank account, make a fraudulent transfer to your account, then ask you to make transfers out. After a couple days the bank will notice the first fraudulent transfer and go after you for the money. Also, I don't know what the definition of money laundering is, but this seems close.

Furthermore, if you look up the registration information of their website here:
http://www.whois.net/whois/tdi-limited.com
You will see they only registered the website on June 26, 2011. So, this big international company has only had a web site for 2 weeks.

Stay away from this scam.

How Sovereign Bank lost me as a customer with one letter

I just got the monthly statement for my Sovereign Bank business checking account. And this lovely notice was on the first page.



If you can't read the image, it says: "Beginning in June, non-customers cashing checks drawn on your Sovereign Bank business accounts will be charged a $5.00 fee by Sovereign Bank unless you have agreed to pay some or all of this fee." It then goes on to describe a non-customer as essentially anyone that does not have an account with Sovereign Bank.

$5 to cash a check? That seems very unreasonable. Is depositing a check into another bank account considered cashing a check? I don't think so, but it isn't entirely clear to me. I'm pretty sure this is aimed at people walking into a bank branch and converting a check to cash.

I don't actually write many checks. In fact, I think the only checks I write are to myself. So, I'm not going to get hit by this fee, but I've had enough of the large banks and their unreasonable fees. Sovereign Bank you've just lost a customer. Local banking, here I come!

WCF/MSMQ/.Net 4.0 stops processing messages–code fix

I recently upgraded a self hosted WCF service to .Net 4.0. Everything seemed to go well, but a few hours after deploying the service messages started piling up in the queue. I check the service host process and it was idle. It was still executing, but the service had stopped pulling messages. After a bit of trial and error I have discovered the problem and hopefully a solution.

The problem

It seems that .Net 4 has changed the behavior of WCF/MSMQ services slightly. If a problem occurs with the queue, the service host faults and stops.

The solution (I think)

Here is the code I came up with to address the problem. I wrote a class that creates the ServiceHost and attaches an event handlers to the Faulted event. If a fault occurs, I abort the ServiceHost and restart a new instance. (This is for a self-hosted WCF service – if you are hosting your service in IIS/WAS, I think you need to create a ServiceHostFactory class.)  Here is my code:

    /// <summary>
    /// In .Net 4, the WCF/MSMQ behavior seems to have changed slightly. Occasionally, the service will fault and not restart causing
    /// messages to get stuck in the queue. This class attempts to abort and re-start the service host in the event of a fault.
    /// </summary>
    /// <typeparam name="T">Your service class</typeparam>
    public class RestartingServiceHost<T>
    {
        protected static readonly log4net.ILog Log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
        ServiceHost _serviceHost;

        public void Start()
        {
            _serviceHost = new ServiceHost(typeof(T));
            _serviceHost.Faulted += new EventHandler(host_Faulted);
            _serviceHost.Open();
        }

        private void Restart()
        {
            _serviceHost.Abort();
            Start();
        }

        private void host_Faulted(object sender, EventArgs e)
        {
            Log.Info("Host faulted. Restarting service.");
            Restart();
        }
    }

To use the class, simply create an instance of this class using the type of your service class:

var host = new RestartingServiceHost<MyService>();
host.Start();

That’s it. It seems to be working so far.

Setting up MVC 3 for Azure with a scripted build

 

I just spent a little time setting up an Azure project using ASP.Net MVC 3 and a scripted build. I thought I would share the solution. Be warned, I'm not an expert in this stuff -- let me know if you have any ideas on how to improve this.

Step 1: Set up the directory structure.

I like to follow a relatively simple directory structure for my projects. Of course you can use your own structure; I like this one.

\ProjectName\src     <-- source code, project files, etc.
\ProjectName\lib     <-- 3rd party libraries
\ProjectName\tools   <-- tools (FxCop, 3rd party build tool components, etc)

For this post, I will be using the project name "Gamma".

Step 2: Create the VS2010 solution

Start Visual Studio 2010 and create a new solution. I like to start with a blank solution and add projects as needed. Save as "\Gamma\src\Gamma.sln"

Add a new Windows Azure project. When you are prompted to add roles to the Azure project, skip this step. At the time of this post, the VS templates do not include an Azure MVC 3 project. To get around that problem. Add the empty Azure project to the solution. Then add a new project to the solution and select an MVC 3 project. Then, in the Azure project, add a "web role project in solution..." and select the MVC 3 project.

So, now you should have \ProjectName\src\ directory with one solution file, a directory for the Azure project, a directory for the MVC project and possibly a directory for the unit test project if you elected to add one.

Step 3: Create command line build scripts

I like to have a command line builds, especially for automating your build with a tool like Hudson or Jenkins. I found a post a while back about automating .Net builds and I really liked the approach. I will try to search for a link later to give credit. You create 3 files:

1. a simple MS Build project file that builds your solution,



2. a script file to kick off the build from the command line and



3. a batch file that allows you to double-click on a file in windows explorer to produce a build.

Here are the file's I use:

build.ps1 -- powershell script for command line builds

if ($args)
{
    & $env:systemroot\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe build.proj /t:$args /verbosity:minimal
}
else
{
    & $env:systemroot\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe build.proj /verbosity:minimal
}

ClickToBuild.bat -- batch file for kicking off a build from windows explorer

PowerShell -Command ".\build.ps1"
pause

build.proj -- MSBuild file for building your solution.

<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>
  <ProjectName>Gamma</ProjectName>
</PropertyGroup>

<Target Name="Package" DependsOnTargets="Clean;DebugBuild">
  <Message Text="Creating Package for $(ProjectName)" Importance="High" />
  <MSBuild Projects="$(ProjectName).sln" Targets="Publish" Properties="Configuration=Debug" />
</Target>

<Target Name="DebugBuild">
  <Message Text="Building $(ProjectName)" Importance="High" />
  <MSBuild Projects="$(ProjectName).sln" Targets="Build" Properties="Configuration=Debug" />
</Target>

<Target Name="Clean">
  <Message Text="Cleaning $(ProjectName)" Importance="High" />
  <MSBuild Projects="$(ProjectName).sln" Targets="Clean" Properties="Configuration=Debug" />
</Target>
</Project>

These are relatively simple. I save them the root of the "src" directory. In Visual Studio, I add a solution folder named "build" and add these 3 files to that solution folder.

The important thing to note is the Targets="Publish" in the package target of the MSBuild file. The "publish" target is what creates the Azure package files that you need for deployment. By default they will be in the \bin\Debug\Publish\ directory of the Azure project.

Note: Azure does not have the MVC binaries by default. You will need to get these to your Azure instance. There are a couple ways to accomplish this. You can either include all the DLLs in your project and set them to "copy local", or you can install MVC3 as part of the Azure startup script. Links to come later.

Let me know if this helped. If I find some time I will add some screen shots.