Tuesday, March 29, 2011

I have always created roles with the execute permissions only through SQL scripts and the reason for this is that I could never figure out how to do it via Sql Management Studio. Well today I figured it out and so here are the here are the steps for setting up a role with execute permissions using Sql Server Management Studio (SSMS).

Why? If you want to control what permissions your users have to the database and want to control it through roles. I used it for defining a separate role that would be used if users needed to have execute permissions on all the stored procs in the database (instead of – per stored proc).

Right click on the roles node under security for your database and select Add New Database Role.

Setup the General properties page

On the securables page, select Search and select all objects of type and click OK

In the next window, select databases and click OK

Back on the securables page, select the database row that just got added and in the Permissions for {DatabaseName}, select grant for the Execute permission.

When you click ok, your role will be created and the steps will be similar to the following script.

Note: this may not be the most secure for your purposes, but the steps can easily be modified to reduce the level at which the execute permissions are provided. (these steps define it at the database level).

When you need to detect if your view or view-model is being instantiated during design time or runtime, the easiest method is to check the IsInDesignTool static property of the DesignerProperties class.

2001 – 2010 – The Era of the Lean Startup: - Customer Development, Agile Engineering and the Lean methodology enforced a process of incremental and iterative development. Startups could now get a first version of a product out to customers in weeks/months rather than months/years

Startups began to recognize that they weren’t merely a smaller version of a large company. Rather they understood that a startup is a temporary organization designed to search for a repeatable and scalable business model.

Friday, March 11, 2011

For the last couple of days I have been battling with TFS2008 and getting our build server to run the unit tests defined in a Visual Studio 2010 solution.

Previously we installed .Net 4.0 and updated the MsBuild path in the tfsbuild.proj file so our VS2010 solutions were building without a problem on the TFS2008 based build server. But the minute I tried to get the build server to run the unit tests in my solution, the build would partially fail and if looked in the BuildLog.txt file, this is the error I got:

Task "TestToolsTask"MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build. [Path\TFSBuild.proj] The previous error was converted to a warning because the task was called with ContinueOnError=true. Build continuing because "ContinueOnError" on the task "TestToolsTask" is set to "true".

Googling the error and you find out that you need Visual Studio 2010 Premium or Ultimate edition to be able to run unit tests as part of your build. So I went ahead and installed VS2010 ultimate and I still got the same damn error shown above.

It turns out that in addition to VS2010 (premium or ultimate) you also need VS2008 Development edition on the build machine. (In addition is the operative word here – you need both!). It turns out that the TestToolsTask is looking for VS2008 dev edition before running even a VS2010 based solution (and I am not sure if this for some required dlls or for licensing purposes – either ways – it sucks) (Obviously the reason I had to battle with this issue was that the build machine was never previously setup to run MsTests – even with Vs2008, else someone would have figured out that they needed VS2008 dev edition on that box).

Once I got VS2008 dev edition on that machine I was able to get the build a little further. HOORAY!

Some other things to note:

Once you get both VS2008 dev and VS2010 premium on that machine, you should delete the workspace used by the TFS service on the build machine (the easiest way to do this is to use the TFS SideKicks tool and search for all the workspaces on that machine and then delete the one that is being used for your build). This allows TFS to rebuild the workspace and all the files, but this time with MsBuild 4.0.

Now that I got one problem fixed, TFS decides to throw another one at me and the error that I get is as follows:

The problem with MsTest is that it always use the generic error code of 1 when it fails. So it makes it extremely hard to figure out what is going on when it fails. I looked through a long list of online articles that had me doing a whole bunch of things and at the end the following is what fixed it for me:

Need to Microsoft.TeamFoundation.Build.targets file to use the VS2010 dll instead of the VS2008 dll for the testToolsTask In the folder: “C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\” on the build machine you will find the file “Microsoft.TeamFoundation.Build.targets”. Edit the following lines: Comment out the original line for the TesToolsTask:

Or use the following node to define a wildcard to select the files that contain the tests:

<TestContainer Include="$(OutDir)\Tests.dll"/>

With that your TeamBuild should be executing all your unit tests.

Code-Coverage:

The only thing that I havent been able to get going is Code-Coverage on my solution. Here is what I have tried:

I have setup the VSMDI to use a testConfiguration for the unit tests. As part of the test-configuration, Code-Coverage is enabled and I have selected the dlls on which code-coverage should be run. With the above settings, some files (like data.coverage) get created in the drop folder, but TFS reports that code-coverage was not run.

Its been known for a while that .Net Reflector v7 was supposed to be a paid version and although I was saddened by that decision by RedGate, I was ok with it.

But what I was not ok with was that when I started up my trusty old copy of v6.1 of .Net Reflector today, it told me that I needed to upgrade to the latest version. But I didn’t want to pay for it so I responded no to the prompt and RedGate promptly went and deleted my reflector.exe file!!!! NOT COOL RED-GATE, Not Cool!

This is the first time I have ever come across a software that doesn’t allow you to run an older version of the software for which we obviously had a license. And definitely it’s the first time I have come across a software that goes to the extent of deleting its file without even asking the user.

Unhappy! unhappy! unhappy!

I hope Red-Gate reviews its policy – as there is no reason why they should cripple their previous free versions of .Net Reflector.

Right click on the redSn0w.exe file and open the Properties window. Select UNBLOCK.

Before running RedSn0w turn off any anti-virus you may have running temporarily (first scan the Redsn0w package before turning of auto-protection).

Run RedSn0w in administrator mode (Right click on RedSn0w.exe and select run as Administrator).

The first screen will have a browse button. Click on it and select the IPSW file that you downloaded in step 1. RedSn0w will process the IPSW file for less than 1 minute after which the Next button will be enabled.

Clicking on Next will process the file.

The only 2 options that you need are “Install Cydia” and “Enable Battery Percentage” (These are the default options).

Click Next.

Now before you hit Next on this screen read the instructions carefully. You need to prepare the device for unlocking

First make sure that your phone is on.

Connect it to your computer

Now hold the power button down until you get the Slide to power off screen

Slide the power off button and power down your phone (remember all this is done while your phone is connected to your computer).

Before clicking next here is what you need to know.

As soon as you click Next you will be asked to hold down the power button for 3 seconds

Next you will be asked to press the Home buttonwithout letting go off the power button for another 10 seconds.

Finally you will let go off the the Power button, but continue holding down on the Home button for 15 more seconds.

Now that you know what is going to happen next, click the Next button and follow the instructions (which will be similar to what I described in 12).

If everything worked correctly, RedSn0w will begin loading the modified firmware onto your phone and then reboot it.

After that the jailbreak process will continue on your phone.

To verify that you managed to Jailbreak your phone all you need to do is check the battery meter (top right corner and it should have a % value next to it. In addition you should see the Cydia app on the phone).

That’s it. Your phone should be jailBroken and you should be able to use it with other cell phone carrier’s sim card (like Sprint)