Brian Chavez - Entrepreneur & Computer Engineer

This is primarily used as notes for me …

As the title suggests, I had a problem with *some* DLL references inside Project.Web\Bin\*.refresh files not being copied during the .wdproj build process.

There were a few blogs out there that offered some solutions like editing the Microsoft.WebDeployment.targets file and removing the Copy “Condition” inside _ResolveReferences target (Line 862). But these solutions bothered me because it did not explain the root cause of the problem.

What was most strange about this problem was that all my builds worked before, so something must have goofed up the build process.

It turns out, your .wdproj file may be out-of-sync with your .SLN file. Double check the following XML elements inside your .wdproj file:

• <SourceWebPhysicalPath> -- You need to triple check that this path is correct,
• <SourceWebProject>GUID|ProjectURL/Name</SourceWebProject> -- The GUID in the <SourceWebProject> XML element must match the web-project GUID in your .SLN file. Also, the ProjectURL/Name should also match the string that follows the web-project GUID in your .SLN file too.

It turns out, if you were using Visual Studio’s built-in Cassini web server, then switched to IIS Express at a later date, your .wdproj may contain stale reference information located in the two XML tags listed above. Specifically, the format of the <SourceWebProject> tag using Cassini is “GUID|ProjectPath”, and “GUID|ProjectURL” for IIS Express. When you convert a website from Cassini to IIS Express, the website’s GUID changes and ProjectPath becomes ProjectURL in the .wdproj. The website GUID and ProjectURL values can be found inside the .SLN file after the change has been made.

If you’re unsure of what GUID|ProjectURL values are needed, simply remove the .wdproj deployment project from solution and add it again (overwriting your previous .wdproj), and Visual Studio will recreate the necessary values inside your .wdproj. Just remember to refresh your .wdproj when switching between IIS Express and Cassini.

Additional Tip 1

Double check your .SLN “E24C65DC-7377-472B-9ABA-BC803B73C61A” (Website Projects) sections of your .SLN file and ensure the AspNetCompiler.PhysicalPaths are correct.

Additional Tip 2

Make sure your website project is set to “build” in the Configuration Manager for your Release configuration.

  

This is important because, during the build process, MSBuild creates “meta projects” (.metaproj) for your website projects that are derived from your .SLN file. The reasoning is, website projects (which differ from Web Application projects) do not have an accompanying “.csproj” project file (which are essentially MSBuild scripts). Project settings for website projects are stored in the .SLN file and the .SLN file is used to create an intermediate (.metaproj) MSBuild script on-the-fly. You never see the resultant intermediate build script emitted from MSBuild by default.

To see the intermediate build script for your website project:

• set MSBuildEmitSolution=1
  (via command-line - environment variable)
  
• msbuild MyProject.sln /property:Configuration=Release /target:Rebuild
  (run MSBuild on your solution)

If your website project is set to build in Release configuration as shown in the pictures above, you should see a few files similarly named “localhost.metaproj” and “MyProject.sln.metaproj” emitted from MSBuild as it transformed your website project settings into intermediate MSBuild scripts. The “localhost.metaproj” files contain MSBuild tasks that read .refresh files and copy .refresh references into your Project.Web\Bin folder.

Ultimately, this will ensure all .refresh files are honored & copied before your .wdproj deployment build script executes.

Additional Tip 3

Ensure your website project and .wdproj has the correct build order in your solution:

Your .wdproj should be somewhat last and definitely after your website project build.

Additional Tip 4

If you want to avoid the extra aspnet_compile from enabling the “build” in tip 2 and you really feel up for modifying your Microsoft.WebDeployment.targets file, simply remove the ! operator from the Copy Condition in:

Removing the ! from the Copy Condition will copy the DLL references into your Web\Bin directory and all should be well.

Hope that helps,
Brian Chavez

Finished writing a C# / .NET implementation of the Dwolla Off-Site Gateway API released under the LGPL.

Code is available on github.

Patches, improvements, suggestions welcome.

Thanks,
Brian Chavez

Recently, Visual Studio 2010 was taking ridiculously long time saving settings from the following locations:

• Tools > Options… window.
• Tools > Import and Export settings … window

Saving settings from these location took about 15 minutes to save! It was seriously frustrating.

I noticed, CurrentSettings.vssettings file was approaching 13MB.

After opening the CurrentSettings.vssettings file I found multiple <ViewBookmark> tags filling up the settings file. They looked something like:

<ViewBookmark Name="D:0:0:{GUID}|… path to file .css …||{GUID}" ViewBookmarkType="DocumentWell" DockedHeight="1399" DockedWidth="1342.97336877197"/>

So, I manually deleted the duplicate lines in the CurrentSettings.vssettings file. The CurrentSettings.vssettings file was reduced to 335KB. Awesome. I opened and closed Visual Studio to see if the settings file still worked and to my surprise, the bloated lines I removed were automatically inserted back into CurrentSettings.vssettings! Wow. Seriously?

After some time tracking down where these lines were coming from, it turns out if you look in the following folder:

C:\Users\USER\AppData\Roaming\Microsoft\VisualStudio\10.0

You’ll find two files “Debug.*.winprf” and “Design.*.winprf” and associated *.winprf_backup files. These files appear to be WPF XAML files that store Visual Studio’s window (and toolwindow) information. If you delete them, Visual Studio will re-create the XAML files using default tool window locations. However, if you want to keep your window settings, you’ll need to manually edit the files and remove the bloated lines that are filling up the XMAL file.

Once you remove the bloated XMAL lines from your *.winprf and CurrentSettings.vssettings file, saving your Visual Studio settings should be quick once again!

Hope that helps,
Brian Chavez

The Problem

I like using RDP but I get very frustrated when the terminal window doesn’t remember the location.

Evert time I connect via RDP, the remote window starts in the top-left corner of my primary screen. It drives me nuts.

In this post, I’ll explain how to save the location of the window without hacking RDP files.

 

Set The Defaults

Run MSTSC:

 

Next, adjust your desired settings in General, Display, and Local Resources….

 

 

Click Save button, DO NOT CONNECT, and Close MSTSC when done.

Essentially, what we’ve done is save these connection preferences to “Default.RDP” (see details at the end of this post).

 

Place The Window

Next connect to the machine using the /v: switch:

 

Move, place, resize, and adjust the terminal window where you want MSTSC to start every time.

NOTE: If you want scrollbars to be removed adjust the height and width of the window now. You may need to click the restore button between the close and minimize button on the top right.

 

Next, Close the terminal window when you’re done and click OK.

MSTSC should now save the last position of the window in “Default.RDP” (see details at the end of this post).

 

Save The RDP file

Run MSTSC again:

Now Click SAVE AS..:

Double click on your new RDP file.

Your new terminal window should start  at the same position every time you double click on your new RDP file.

 

The Details: The Default Settings File

MSTSC stores default connection preferences in a hidden file called “Default.rdp” located in:

[System.Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments)

# Windows 7: %USERPROFILE%\Documents\Default.rdp

# Windows 2000 / XP: %USERPROFILE%\My Documents

Note: If you don’t see Default.rdp, you’ll need to turn on “Show Hidden Files”.

Default.rdp is the default settings (& window state location) for MSTSC.

Brian Chavez

Gee, setting up an SNTP/NTP server in Windows is not intuitive.

The good news is: When configured correctly, you can use the Windows Time (W32Time) service as an SNTP/NTP server for both windows and non-windows SNTP/NTP clients.

Here's how to do it:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry entry:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\

3. In the right pane, right-click AnnounceFlags, and then click Modify.
4. In the Edit DWORD Value dialog box, under Value data, type 5, and then click OK.
5. Enable NTPServer.
   1. Locate and then click the following registry subkey:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
                                                      Services\W32Time\TimeProviders\NtpServer\

   2. In the right pane, right-click Enabled, and then click Modify.
   3. In the Edit DWORD Value dialog box, type 1 under Value data, and then click OK.
6. Exit Registry Editor.
7. At the command prompt, type the following command to restart the Windows Time service, and then press ENTER:

   net stop w32time && net start w32time

This should get you setup with minimal registry hack impact.

Tips

• Make sure W32Time is set to Automatic startup mode.
• Make sure UDP 123 is allowed through your firewall.
• Use this InternetTime program to help you debug connectivity to your SNTP/NTP server.
  internettime.zip

Hope that helps,
Brian Chavez

I migrated Bit Armory's servers from Virtual Server 2005 R2 to Microsoft Windows 2008 R2 Hyper-V and ran into a lot of friction.

Anyway, the migrated servers had annoying errors from the Service Control Manager saying:

Event Type:    Error
Event Source:    Service Control Manager
Event Category:    None
Event ID:    7000
Description:
The Parallel port driver service failed to start due to the following error:
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

The problem can easily be solved by disabling the "Parvdm" device & driver service.  Open Device Manager, Check "Show hidden devices", find "Parvdm" in "Non-Plug and Play Drivers".

Then all should be well. Again, just more friction from Microsoft.  They really need to test this stuff.

Hope that helps,
Brian Chavez

Google's Checkout Merchant fees are increasing May 5th 2009.  This so called new "multi-tier" pricing is the SAME EXACT pricing as PayPal.  You can't even CALL Google for Checkout for telephone support!?!

Quick! Join the Facebook group:

http://www.facebook.com/group.php?gid=57485523675

Merchants Against Google Checkout Fee Hikes!

Let's show the Internets can fight back!

PAYPAL FEES

GOOGLE CHECKOUT FEES

?!?!

--Brian Chavez

Well, I was working on killing a bug in JavaScript and I needed Sys.Debug.trace() to help.  I used Script#, and the compiler yelped this error at me:

Check that your C# source compiles and that you are not using an unsupported feature.

Whoops.  Didn't find much around and on good ole' Google, so I didn't have much of an option.  Turns out, I was using namespace-qualified types like so:

Just change your code to:

And the compiler should be happy again.

Script# is a great tool to add to your tool belt along with MS AJAX and jQuery.  The Script# suite isn't exactly full-feature-tested compiler yet, but it's getting there!  Thanks again Nikhil Kothari!

Hope that helps!

Brian Chavez

Muah.  While updating to NAnt 0.86, I was stuck with the following error while trying to execute a <script> task:

The name 'Regex' does not exist in the current context

I was using a <script> task to do some RegEx some files apart of the build process.  Well, turns out that NAnt 0.86-beta2 has a breaking change.  System.Text.RegularExpressions is now removed by default from the imported assemblies of <script> tasks.  Oh well...

The following should get you back on track:

Just add the <imports> and <references> section to the <script> task and all should be well again! :)

Brian Chavez

Bit Armory, Inc. has decided to finally make the move to IIS7 for production.  Let's hope it goes well.

 

First Impressions:

• Performance seems a little better
• Better ASP.NET MVC support
• Easier Setup

I did have a problem with Subtext and IIS 7 yelping back an error:

"System.Web.HttpException: Request is not available in this context"

Thanks to Lance Fisher, the fix was easy, simply set "Classic .NET AppPool" in Manage Web Site > Advanced Settings ... should do the trick.

 

Hope that helps!

Brian Chavez