Tuesday, May 24, 2005

Connecting a Pocket PC emulator to host internet in Whidbey

This tip is for developing environment which has Whidbey Beta 2. I do not know if it will work (probably won't) on a Virtual PC environment.

If you are trying to connect your Pocket PC emulator to the internet because you are developing/deploying perhaps a web service on your host system, and you want your emulator to be able to consume it in your debugging, here is a few things in sequence I have tried to get it to work:

- Restart your computer. Yes.
- Open your .sln by double-clicking it in your Explorer, not by opening your Whidbey and then selecting it from your File/"Recent Projects". Apparently there is a funky difference.
- Run F5 to bring up the emulator.
- It will probably tell you "Cannot connect to device", but that's okay.
- In Whidbey, go to Tools/"Device Emulator Manager", set your emulating device to Cradle.
- Reset the state of your emulator.
- Close down the emulator.
- Run F5 again to bring it back up.
- In your emulator Connections/Advanced/"Select Networks", select "My Work Network" in the first droplist for programs that need access to the internet.
- Go to its Edit/"Proxy Settings", uncheck the box "This network connects to the internet". Notice this box will automatically be checked again by the emulator once it can connect to the internet.
- And finally, verify that you have turned your firewall software off.

This would work in the emulator IE whether you type "http://localhost/MyService.asmx" or "http://localhost/MyService.asmx". If I were you, I would see if I could even connect to Google first in your emulator IE before testing the web service.

Tuesday, May 17, 2005

Dynamic deployment config settings

Using Visual Studio .NET 2003, there are different options to dynamically use app/web.config settings depending on what environment the build is deployed on. One of which is in your code, use preprocessor directives like #if, #elif, and #endif. I don't like this approach, period. This is really ugly. What if you have 5 deployment environments? You will end up with values with keys "dbConnStringDev", "dbConnStringTest", "dbConnStringQA", "dbConnStringProd", etc.

Another option is have inside your app/web.config file, just create one key-value pair for each setting regardless of how many deploying environments you might have (eg. ), and then after each deployment, manually (or automate this by some scripts) go and edit the settings for all these. Well... this is just as bad as a single mistype would deem a deployment failed.

A third option would be, if you have separate a set of physical machines per deployment environment, one could use each machine's machine.config as the definitive setting storage, and then override them with local app/web.config in for example your developer's .NET projects. Question arises if for example you have five different deployment environments (dev, test, QA, stage, and prod) but you only have two boxes for your web services server across all of these environments: how do you direct traffic for dev, test, and QA to box A while stage and prod to box B. It's the same problem all over again.

The solution (well, not really) I have found so far is this. In the .csproj that could house a app/web.config file, you can find the following lines for each solution configuration:

<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = "app.release.config"
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = "bin\Release\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
...

if you create a new .config file for each deployment environment that you have, then create a new solution configuration for each deployment envionment (eg. Debug, Release, QA, Stage, Production), then change that bolded line for each deployment into the appropriate .config file, then create a Setup project in your solution and build it with the solution configuration you want for your deployment, the output .msi will include *a* app.config file, with it being replaced with the file you specified in the above bolded text. So in the example above, app.release.config will be used and renamed to app.config when the output .msi is deployed onto the environment.

This is so far the cleanest solution for me. But it does tie you into using Setup project for your deployment configuration. And from what I have heard, .msi has not been a good deployment strategy for complex application deployment (yes, the fact that there is a relational database built into a .msi does not make it suit for enterprise level if it is complex to use).

Still looking into alternatives... on a side note, the fact that Microsoft is switching from "no-touch deployment" into "one-click deployment" means to me that the marketeers at MS is going one step to far in their marketing effort =P

Thursday, May 05, 2005

Whidbey Beta 2 Visual J# Redistributable, cannot load package problem

I was having a tough time to install Whidbey Beta 2 onto not my Virtual PC instance, but onto my host OS Windows XP Prof. I installed it three times in total, fortunately I have my laptop backed up before I acted.


The problem I was having was that during installation, the wizard tells me that the component 'Microsoft Visual J# Redistributable Package 2.0 Beta 2' installation was unsuccessful. The Whidbey install went on, but as I open a .NET 2.0 solution, it gives me some infamous package loading error:

Could not load type 'Microsoft.VisualStudio.Shell.Interop.IVsRunningDocumentTable2' from assembly 'Microsoft.VisualStudio.Shell.Interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

and I then I could not open the desgin view of a simple winform page in my Smart Device Compact Framework project.

The solution was I brought back the image I took earlier, downloaded this cleaner tool from Aaron Stebner, ran it. Then the next time I install Whidbey it no longer gives me the J# Redistributable problem. My winform page now loads fine.