0

The reason for my slightly odd question is simple. I'd like to run my console as 32-bit on my dev box simply because of the convenience of edit-and-continue, which can be a time-saver for silly mistakes - just fix them on the spot and go on.

But I'd also like not to have to change the build configuration, because it's under source control and I'll forget to set it back to "any cpu" and we'll end up deploying the wrong image version if I set this to "x86".

Is there a way that let's me get the best of both worlds?

The Dag
  • 1,811
  • 16
  • 22
  • possible duplicate of [Environment variable to force .NET applications to run as 32bit](http://stackoverflow.com/questions/619155/environment-variable-to-force-net-applications-to-run-as-32bit) – Hans Passant Jul 16 '12 at 15:48

2 Answers2

1

You can set a separate Project Configuration for Debug and Release, and also create your own. I'd create a third Project Configuration called Local and set that Platform to 32-bit (x86). You can work from that configuration. Switch to release when you need to create a deployable version before you Build.

As an additional safeguard, you can can set your SVN to "ignore" the Local build folder you created earlier to make sure it doesn't make it into your SVN.

The Project Configuration settings can be accessed in the DropDown beside the Green "Play" button in Visual Studio. It defaults to reading "Debug", or sometimes it will say "Release".

Any help?

Hairgami_Master
  • 5,429
  • 10
  • 45
  • 66
  • I don't actually intend to ever build a release build! My console is a batch that spends most of its time waiting for service calls or database interactions to complete, and the value of building release is minimal. My software of course never has any bugs ;) but the value of a full exception stack trace with code locations in my logs is far greater than the value of shaving milliseconds off multiple-minute jobs. – The Dag Aug 08 '12 at 10:17
  • As for the project configuration, VS with TFS seems to absolutely want to share these things with everyone. I'd really prefer a solution that can be easily applied only to my dev box and without any possibility of introducing an error. I'll now look into the CorFlags.exe tool (mentioned in the thread linked by Hans Passant above), which perhaps does the trick. Thanks for the effort anyway. – The Dag Aug 08 '12 at 10:21
0

In the end, I opted for the following solution:

Add a new console app project to my solution called 32bitLauncher. Set the build configuration on this one to target x86 only. Then make my various batch classes and their main methods public, and define multiple entry points in the launcher, like this:

class Prefill
{
    static void Main(string[] args)
    {
        PrefillBatch.Main(args);
    }
}


class Correspondence
{
    static void Main(string[] args)
    {
        CorrespondenceBatch.Main(args);
    }
}

Now I can select the startup object in the property pages for the launcher when I want to switch between batches, actually more convenient than changing the startup project (because I anyway need to go into the property pages to set command-line arguments). This forces 32-bit execution even on 64-bit hardware, and lo and behold, I can edit-and-continue!

The Dag
  • 1,811
  • 16
  • 22