Buy Quinine Without Prescription, Today I received an email informing me that I have been awarded the Microsoft Community Contributor Award.  This is the second time I have been awarded this particular award and it feels just as good this time as it did last time.  I’m not sure how you go about getting nominated for this award, but apparently I am doing something right.

I would like to thank whoever nominated me for this award and Microsoft for listening to that person.  I would most of all like to thank the community.  Without the support of the community I would probably still be a cop. Oh, australia, uk, us, usa, Discount Quinine, you probably didn’t know that about me.

Similar posts: Ventolin For Sale. Synthroid For Sale. Buy Ultram Without Prescription. Topamax For Sale. Amoxicillin For Sale. Order Ultram online overnight delivery no prescription. Inderal schedule. About Hydrochlorothiazide. Ventolin australia, uk, us, usa. Human Growth Hormone interactions.
Trackbacks from: Buy Quinine Without Prescription. Buy Quinine Without Prescription. Buy Quinine Without Prescription. Buy Quinine Without Prescription. Buy Quinine Without Prescription. Online buy Quinine without a prescription. Is Quinine addictive. Quinine over the counter. Order Quinine from United States pharmacy. Generic Quinine.

But I didn’t know you could profile a Silverlight app.

I didn’t until I started doing some digging online. Now, the Silverlight profiling story (at least from what I’ve seen/tried) is not near the easy of say Redgate ANTS Performance Profiler. However, it’s do-able. (And with this helper script – hopefully a little simpler?)

How can I profile a Silverlight Application?

I would recommend you read the following blog, which explains one way of doing it very well.

http://blogs.msdn.com/profiler/archive/2010/04/26/vs2010-silverlight-4-profiling.aspx

So… what’s this script for?

If you read the blog above, or have done this before, then you probably noticed that there was quite a series of commands you had to execute before you could wind up with a performance report.

I threw together a quick little PowerShell script in an attempt to automate smooth out the process.

Hot do I use it?

1. Download the script & save it somewhere. http://github.com/staxmanade/Scripts/blob/master/SilverlightProfiler.ps1
2. Open the PowerShell console. cd to the directory your xap/assemblies are stored.
   (EX: {myProject}\Bin\Debug\ )
3. Execute:
   {pathToScript}\SilverlightProfiler.ps1 -urlPath "{myProject}\Bin\Debug\TestPage.html"
4. When your done profiling press enter to signal that your done.
   Once complete, it will print the location your profiling report was saved. You can then open it with Visual Studio.

Couple of disclaimers.

• Some paths are hard-coded to my x86 machine.
• I had troubles running the built in visual studio .bat files (from powershell) that are supposed to set the environment variables. So I extracted out what vars I could find to make it work.
• I’m not a profiling expert – just hacked this together to get it to work for me.

I hope this is useful, and if you know of a better way, I’m always interested in hearing your feedback.

That said, there is still room for improvement and both the team and I understand there are still opportunities to improve. In all seriousness, the team at Microsoft wants to make TFS an approachable, no-brainer install decision for .NET teams, even small ones. This means they want to be able to compete for your attention with the likes of SVN, Git, Jira, Perforce, and anyone else making collaboration tools for developers.

The point of this post is for you to help me know what feedback I can give the TFS product development team as they look ahead to the next release of TFS. I am looking for legitimate feedback I can give the team on how to improve the TFS product.

Please bear in mind that I am interested in your feedback on TFS 2010, as TFS 2008 was improved upon 10 fold in the latest release. Also, I am not necessarily looking for feedback on Visual Studio, just the TFS side of the house. Please realize that the team who makes this product at Microsoft is just as committed and passionate about making great software as you are. They just really need your feedback to make the thing you want. In fact, they want to make a tool that every developer loves to use. Really. So what needs to change to make that the case?

Recall that TFS functionality is broken into the following major areas and I am looking for feedback on the 2010 version.

• Version Control
• Work Item management
• Team Foundation Build
• SharePoint integration (optional)
• Reporting and SSRS Integration (optional)

Thanks for anything you have. Thank you also for being respectful and not making this a bash-fest.

So here is a hidden performance increasing jewel you might find useful.  We can set the default open mode to be in full XAML view.

First thing you need to do is in Visual Studio go to your Tools ==> Options ==> Text Editor ==> XAML ==> Miscellaneous.  There you will see an option for “Always open documents in full XAML view”.  Check that box.

Now every time you open a XAML file it will open in full XAML view and give you one less thing to gripe about.

Folks, this product is getting better. That stands to reason. After all, this is basically version 3 of the product and you know what they say! Version 3 is the one to buy. Most of the kinks are worked out now.

Now, I won't pretend for a moment that Team Foundation Server hasn't had its challenges fitting in with agile teams. I think that has come from a history of development by a team that itself was learning and growing just like the rest of us. Now that many of the teams within Microsoft are practicing some form of iterative development with completed cycles of "all the way done", we are starting to see the influence in the tools they are producing. And the effect is not half bad.

I have been using Visual Studio 2010 for a few months now, and with the recent release of the RC, I can see:

1. Performance is getting better (XAML).
2. Features are getting more solid (fewer exceptions)
3. The polish of the overall user experience is becoming a great example of an application I am happy to look at all day long.
4. The Team Foundation Server features being added are consistent with what we are learning to be effective as an agile community.

So, where's the meat? What are these shiny features of which you speak, Mr. Starr? Well, here is a short sample because I am sitting in an airport listening to the chaos and I can't think of it all.

I should also say that this is a very small list of features that I personally am really excited about. The rest of the world probably has other things they care about. These are mine because I believe they have to potential to really change life on a team for the better.

Layer Diagrams

There is a major focus in this release to add UML support to Visual Studio Ultimate. OK, not a huge fan and I know some people will dog on this feature, but I am all about the Layer Diagrams. These are diagrams that we can create just like the UML diagrams that Visual Studio now supports, but the value of a Layer Diagram is that it has teeth and can bite back.

Here's how it works:

1. Create a Layer Diagram.
2. Draw your favorite design pattern or desired architectural separation model using tools in the Toolbox. In a simple example, this might be to create a model of the MVP pattern. In a large example this model might show the multiple layers in my solution that uses CSLA, Silverlight with MVVM, WCF, and Entity Framework. (Hi, Scott J You knew that was for you.)
3. Add some things to it from your solution. Drop things onto the diagram and into the boxes like classes, namespaces, and Visual Studio projects.
4. Now you can generate dependencies between these things and see the existing relationships. Yawn. Cool, but we get this with dependency diagrams, too.
5. Validate the model.
   
   Wait for it. . . Grok it. . .

   
   You got it! Yeah, that's right. Validate the LOGICAL model of your application. This is so sweet it comes on a stick. This means that not only can I verify I haven't violated my design with a bad reference or super egregious abstraction hole, but I can make this validation part of the build process and catch it if I accidently violate my own design later. Where I come from, they call that cool.

Way Better Work Items

This is non-trivial for teams who live every day of their lives in Team Foundation Server to manage their requirements and work queues. Sure, we might all prefer note cards on the wall, but for many this is simply not possible. And for those folks who use Team Foundation Server to manage their notecards, there are some great new things to make that task easier.

1. Hierarchical relationships between Work Items.
2. Agile planning Workbooks.
3. Seamless Team Project Dashboards.
4. MSF Agile 5.

Gated Check In

This is a feature of Team Foundation Build that will actually build and test your software before a check-in is committed to Source Control. The mechanical effect of this is simple: Code that would break the build is never committed to Source Control. The implications are far larger, though. Think it through for a moment. What would change in your daily life if you flat out were unable to commit code that breaks the build? The short answer is, "Quality goes up." I bit more verbose answer is that I need to be more careful before committing my code.

Yes, I know other vendors have had this feature for a while. So what? So, Team Foundation Server shouldn't have it too? It rocks and now we get it in Team Foundation Build.

IntelliTrace

I am not even sure how cool this is yet, only that it is. This feature is also known as Historical Debugging and gives the ability to step back and forth through call stacks and watched variables during a debug run. To be clear, that's Back and Forth through time. So, the first time I hit the breakpoint, here was the status of the code. The second time it was this. And so on. Also, I can inspect all this data on system events (like CLR events) and can therefore tap into my app at a lot of different levels.

Now, I know that you don't need debuggers anymore because every line of code we write is Test Driven and that means we don't need debuggers, right? Yeah, sure you never need a debugger. As I said, this is just a wicked tool, but I am not yet sure how wicked. The community will definitely ferret that out over time.

Other Stuff

This only scratches the surface of what's in Visual Studio and Team Foundation Server 2010. There are a lot more things, many of them bigger and higher profile than the things I mentioned. I just happen to be in love with these particular features at the moment. As I get deeper into things, I will let you know what I see.

One last thing, I know these tools get a lot of flak in some communities, but I feel comfortable with them. I also understand that many developers out there in the world don't get to choose their tools. Often tools are assigned. What I see is that the 2010 versions of Visual Studio and Team Foundation Server really have raised the bar. I don't feel like teams are still having to compromise on tooling to get everything they need in an integrated environment.

Will I still run R#? Well, yeah.

A typical way to load an assembly within PowerShell is to use the Assembly.LoadFrom(filePath)

# Powershell

[System.Reflection.Assembly]::LoadFrom($assemblyPath)

Except the problem with this (in my case) was it would lock the file for the lifespan of the PowerShell console instance. I didn’t want to have to close and re-open the PowerShell console every time I need to run a build so there had to be a work-around for this.

After searching the web for a solution, I couldn’t find anything that was “easy” and worth the effort to get it to work.

EX: One solution was to create a new AppDomain, do the necessary work and the close the AppDomain which would release the lock on the file.

I’ve never done this myself, and even thought there is example code out there to get this accomplished, it just seemed over the top for what I was trying to do, and back to my previous criteria it wasn’t “worth the effort to get it to work”

Then I remembered in a previous life I used an overload that took an array of bytes to load the an assembly.

[System.Reflection.Assembly]::Load($assemblyBytes)

After spiking it in PowerShell with the below test. I was quite happy with the solution, so I thought I’d throw it out there.

Just stream the assembly from disk into a byte array manually, and call assembly load from there.

Here’s my test case which shows that the file is not locked after it was loaded into the PowerShell runtime

$file = ".\Moq.dll"
$tempFileName = ".\Moq-Renamed.dll"

$fileStream = ([System.IO.FileInfo] (Get-Item $file)).OpenRead();
$assemblyBytes = new-object byte[] $fileStream.Length
$fileStream.Read($assemblyBytes, 0, $fileStream.Length);
$fileStream.Close();

$assemblyLoaded = [System.Reflection.Assembly]::Load($assemblyBytes);

# notice that we can move the file on disk after 
# it's loaded into the powershell runtime
Move-Item $file $tempFileName
Move-Item $tempFileName $file 

# and display the assembly information to show we still have it in memory
echo $assemblyLoaded

After that test passed, and the main reason I wanted to do this, I wrote the “get-assembly-version” PowerShell function.

function get-assembly-version() {
    param([string] $file)
    
    # load the assembly bytes quickly - as to not lock the file for too long
    $fileStream = ([System.IO.FileInfo] (Get-Item $file)).OpenRead()
    $assemblyBytes = new-object byte[] $fileStream.Length
    $fileStream.Read($assemblyBytes, 0, $fileStream.Length) | Out-Null #out null this because this function should only return the version & this call was outputting some garbage number
    $fileStream.Close()
    
    # return the version of the assembly
    [System.Reflection.Assembly]::Load($assemblyBytes).GetName().Version;
}

$version = get-assembly-version(".\Moq.dll")

echo "Loaded v$($version.Major).$($version.Minor).$($version.Build).$($version.Revision) version of $file"

UPDATE:

Martin commented below on a much better solution to the assembly version info problem. Amazing how complicated we can make things if we don’t know the path.

function get-assembly-version() {
    param([string] $file)
    
    $version = [System.Reflection.AssemblyName]::GetAssemblyName($file).Version;
    
    #format the version and output it...
    $version
}

Over time, the bandwidth problems were fixed, and as sometimes happens the WSUS server crumbled to dust.  For the most part nobody noticed – new servers and clients were not configured with the WSUS policy, downloading their hotfixes direct from Microsoft through plentiful bandwidth.  Unfortunately, older server and clients were left in the dark, sending cries out to a WSUS URL that will never respond...  oops

To Fix (and get your automatic updates to work again):

Delete the registry key at “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate”.  For fun, restart the “Windows Update” service (not sure if this is necessary). 

I found this VBS file to be useful in figuring out if a server was still trying to use an old WSUS install, or if the problem was group-policy related. 

I am sitting in the keynote on Tuesday and thinking about the week. In addition to the

Wait? What the… Wordpress moving into the Azure cloud? Sweet!

volunteer sessions I am doing for INETA, I am hosting a Birds of a Feather session with Mike Vincent. Our BOF is this afternoon and is entitled, “Agile Tales of Triumph, Tribulation, Tools, and Teams”. Drop by and join the discussion to learn

Code name Dallas: A uniform way to access data in the cloud and mash it all up.

and share what really works.

It has been very cool to meet many of the Pluralsight instructors for the first time. We all live in different parts of the world, and PDC provides that opportunity for us to

Everyone get your 3D glasses on! Oh, that was very anti-climactic.

all actually shake physical hands rather than electronic ones.

Also, drop by the Pluralsight booth and share your developer stories with me. Here’s the sneak peek as to why: Pluralcast. More on that in another post. Suffice

I think that guy onstage is showing an iPhone and talking about how easy it was to write an app for it. Weird.

to say there will be some changes in the Elegant Code Cast.

Did he just say, “Create applications for the good of the republic?” Seriously?

Lastly, if you see me running around the halls, please stop me and say, Hello.” It’s very cool to be able to meet people I usually only get to chat with online. If you are looking for a great developer team to build your next big thing, we can talk about that, too!

Please stop saying “3 screens in the cloud.”

Ray Ozzie final points from the keynote:

1. Bet your next user experience on Windows 7
2. When thinking of the cloud, bet on Azure.
3. Take a moment to think about how the world is changing and the potential role of cloud in that world.

I’m writing a very basic WebPart to get started with SharePoint – this web part will display a list of links to other applications that the user is authorized to use.  The source of this data (names, URLs, etc.) comes from an external-to-SharePoint system, accessed through another C# assembly.  Once the web part gets the data there is some more processing to be done – we need to do more than just blindly display a list of URLs.  Rather than get into details I’m just going to do some handwaving here and say that “if you have access to X, then {stuff happens}, or if you have access to Y then {other stuff happens}.”  You know, business logic, stuff that is good to test.

the first thing I need to do is get business logic out of the WebPart and into something that I can write without having to reset AppPools over and over, not to mention have some unit tests to verify I’m going in the right direction.  So, I created a standard application service class which has a dependency on the external authorization system, via constructor injection. 

public class AuthorizedAppsService : IAuthorizedAppsService
{
  private readonly ExternalAuthorizeService authService;

  public AuthorizedAppsService(
    ExternalAuthorizeService authService) 
  {
    this.authService = authService;
  }

  public AuthorizedApplications GetAuthorizedApplications(
                                  string userName)
  {
    var allApps = authService.AuthorizedApplications(userName);
    // business logic stuff happens here
    return thoseResultsWeJustFiguredOut;
  }
}

Next, I created a StructureMap Registry class to scan my assemblies, as well as adding in the details of how to create this external authorize service, using the typical method:

public class MyRegistry : Registry
{
  public MyRegistry()
  {
    Scan(scanner => {
      scanner.TheCallingAssembly();
      scanner.AssemblyContainingType(typeof(MyRegistry));
      scanner.WithDefaultConventions();
      });

    ForRequestedType<ExternalAuthorizeService>()
      .AsSingletons()
      .TheDefault.Is.ConstructedBy(c => Provider.GetService());

    // other dependency configuration...
  }
  public static void InitializeForSharepoint()
  {
    ObjectFactory.Initialize(init => init.AddRegistry<MyRegistry>());
    ObjectFactory.AssertConfigurationIsValid();
  }
}

And then, what remains is to have SharePoint call my StructureMap initialization when my SharePoint application starts up.  In an MVC or WebForms app, I’d just add code to the appropriate place in Global.asax.cs, but in SharePointLand, this is looked down on.  Instead, the preferred mechanism seems to be to use an HttpModule and a FeatureReceiver to plug the Module into the app’s web.config.

public class MyStartupModule : IHttpModule
{
  public void Init(HttpApplication context)
  {
        ConfigureOtherStuff();
        MyRegistry.InitializeForSharepoint();
  }
  public void Dispose() { }
}

And then the FeatureReceiver to alter the app’s Web.Config looks something like this (note I borrowed most of this code from another sample SharePoint project:

//
// this is borrowing heavily from http://www.codeplex.com/SPAXO
// 
public class StartupFeatureReceiver : SPFeatureReceiver
{
  public override void FeatureActivated(
        SPFeatureReceiverProperties properties)
  {
    var webApp = properties.Feature.Parent as SPWebApplication;
    AddWebConfigEntry(webApp);
    UpdateApp(webApp);
  }

  public override void FeatureDeactivating(
        SPFeatureReceiverProperties properties)
  {
    var webApp = properties.Feature.Parent as SPWebApplication;
    RemoveWebConfigEntry(webApp);
    UpdateApp(webApp);
  }


  private static void AddWebConfigEntry(SPWebApplication webApp)
  {
    SPWebConfigModification mod = GetModification();
    var existingModifications = 
             new List<SPWebConfigModification>(
                      webApp.WebConfigModifications);
    if (existingModifications.FindIndex(
                    value =>
                        value.Name == mod.Name &&
                        value.Value == mod.Value &&
                        value.Owner == mod.Owner) == -1)
    {
      // If the modifcation does not already exist 
      // add the entry to the config
      webApp.WebConfigModifications.Add(mod);
    }
  }

  private static void RemoveWebConfigEntry(
            SPWebApplication webApp)
  {
    SPWebConfigModification mod = GetModification();
    webApp.WebConfigModifications.Remove(mod);
  }

  private static SPWebConfigModification GetModification()
  {
    string asmName = typeof(StartupModule).AssemblyQualifiedName;
    string typeName = typeof(StartupModule).FullName;

    return new SPWebConfigModification
      {
        Path = "configuration/system.web/httpModules",
        Name = String.Format(CultureInfo.InvariantCulture,
                "add[@name='{0}'][@type='{1}']",
                typeName, asmName),
        Sequence = 0,
        Owner = asmName,
        Type = SPWebConfigModification.
                    SPWebConfigModificationType.EnsureChildNode,
        Value = String.Format(CultureInfo.InvariantCulture,
                  "<add name='{0}' type='{1}' />",
                  typeName, asmName)
      };
  }

  private static void UpdateApp(SPWebApplication webApp)
  {
    // Update the Web App and apply the changes 
    // to all servers in the farm
    webApp.Update();
    webApp.Farm.Services
        .GetValue<SPWebService>()
        .ApplyWebConfigModifications();
  }
}

Folks, this product is getting better. That stands to reason. After all, this is basically version 3 of the product and you know what they say! Version 3 is the one to buy. Most of the kinks are worked out now.

Now, I won't pretend for a moment that Team Foundation Server hasn't had its challenges fitting in with agile teams. I think that has come from a history of development by a team that itself was learning and growing just like the rest of us. Now that many of the teams within Microsoft are practicing some form of iterative development with completed cycles of "all the way done", we are starting to see the influence in the tools they are producing. And the effect is not half bad.

I have been using Visual Studio 2010 for a few months now, and with the recent release of the RC, I can see:

1. Performance is getting better (XAML).
2. Features are getting more solid (fewer exceptions)
3. The polish of the overall user experience is becoming a great example of an application I am happy to look at all day long.
4. The Team Foundation Server features being added are consistent with what we are learning to be effective as an agile community.

So, where's the meat? What are these shiny features of which you speak, Mr. Starr? Well, here is a short sample because I am sitting in an airport listening to the chaos and I can't think of it all.

I should also say that this is a very small list of features that I personally am really excited about. The rest of the world probably has other things they care about. These are mine because I believe they have to potential to really change life on a team for the better.

Layer Diagrams

There is a major focus in this release to add UML support to Visual Studio Ultimate. OK, not a huge fan and I know some people will dog on this feature, but I am all about the Layer Diagrams. These are diagrams that we can create just like the UML diagrams that Visual Studio now supports, but the value of a Layer Diagram is that it has teeth and can bite back.

Here's how it works:

1. Create a Layer Diagram.
2. Draw your favorite design pattern or desired architectural separation model using tools in the Toolbox. In a simple example, this might be to create a model of the MVP pattern. In a large example this model might show the multiple layers in my solution that uses CSLA, Silverlight with MVVM, WCF, and Entity Framework. (Hi, Scott J You knew that was for you.)
3. Add some things to it from your solution. Drop things onto the diagram and into the boxes like classes, namespaces, and Visual Studio projects.
4. Now you can generate dependencies between these things and see the existing relationships. Yawn. Cool, but we get this with dependency diagrams, too.
5. Validate the model.
   
   Wait for it. . . Grok it. . .

   
   You got it! Yeah, that's right. Validate the LOGICAL model of your application. This is so sweet it comes on a stick. This means that not only can I verify I haven't violated my design with a bad reference or super egregious abstraction hole, but I can make this validation part of the build process and catch it if I accidently violate my own design later. Where I come from, they call that cool.

Way Better Work Items

This is non-trivial for teams who live every day of their lives in Team Foundation Server to manage their requirements and work queues. Sure, we might all prefer note cards on the wall, but for many this is simply not possible. And for those folks who use Team Foundation Server to manage their notecards, there are some great new things to make that task easier.

1. Hierarchical relationships between Work Items.
2. Agile planning Workbooks.
3. Seamless Team Project Dashboards.
4. MSF Agile 5.

Gated Check In

This is a feature of Team Foundation Build that will actually build and test your software before a check-in is committed to Source Control. The mechanical effect of this is simple: Code that would break the build is never committed to Source Control. The implications are far larger, though. Think it through for a moment. What would change in your daily life if you flat out were unable to commit code that breaks the build? The short answer is, "Quality goes up." I bit more verbose answer is that I need to be more careful before committing my code.

Yes, I know other vendors have had this feature for a while. So what? So, Team Foundation Server shouldn't have it too? It rocks and now we get it in Team Foundation Build.

IntelliTrace

I am not even sure how cool this is yet, only that it is. This feature is also known as Historical Debugging and gives the ability to step back and forth through call stacks and watched variables during a debug run. To be clear, that's Back and Forth through time. So, the first time I hit the breakpoint, here was the status of the code. The second time it was this. And so on. Also, I can inspect all this data on system events (like CLR events) and can therefore tap into my app at a lot of different levels.

Now, I know that you don't need debuggers anymore because every line of code we write is Test Driven and that means we don't need debuggers, right? Yeah, sure you never need a debugger. As I said, this is just a wicked tool, but I am not yet sure how wicked. The community will definitely ferret that out over time.

Other Stuff

This only scratches the surface of what's in Visual Studio and Team Foundation Server 2010. There are a lot more things, many of them bigger and higher profile than the things I mentioned. I just happen to be in love with these particular features at the moment. As I get deeper into things, I will let you know what I see.

One last thing, I know these tools get a lot of flak in some communities, but I feel comfortable with them. I also understand that many developers out there in the world don't get to choose their tools. Often tools are assigned. What I see is that the 2010 versions of Visual Studio and Team Foundation Server really have raised the bar. I don't feel like teams are still having to compromise on tooling to get everything they need in an integrated environment.

Will I still run R#? Well, yeah.