I am struggling with the purpose of the build configuration manager in Visual Studio 2008. Specifically I am interested in knowing what it does when developing a console application and also a web application (web application project). Does setting it to Debug or Release mode make any difference when you are developing and running the application in the context of VS2008? What does it to when you want to build the solution?
The Build Configuration Manager allows you to set different combinations of project build options for a solution. For example, say you have a solution with 4 projects, log4net, a DAL, a Business layer and the Website. Most times you'll want to run the website and business layer in debug, but the DAL and log4net in release mode. Sometimes you'll want to run the DAL in debug too, but only on a rare occurrence will you want to run everything in debug. The config manager lets you define configurations like that.
Additionally, you could define a x64 build that had some projects target x64 and others target AnyCPU depending on need. Or even a build target that excluded specific projects and included others depending on need.
So in short, the config manager lets you control the inter-process build relations at a level beyond the simplistic debug-all or release-all.
I'd also guess, that 99% of the time you won't need to mess w/the config manager anyway. :-)
I've found this tool incredibly useful in the following situations :
1- You have a lot of projects in a solution, and you want to build only the project you're currently working on (which takes 10s instead of 2mn)
2- You have to produce on a regular basis different type of builds (debug vs release, x64 vs x86, etc.)
To answer your question regarding differences between debug and release mode, it definitely makes a difference. Typically, VS will compile your code "as is" when building in debug mode, while it will optimize (ie inlining, etc.) things in release mode.
For example, if you build this code :
public bool Foo(){
return true; // put a breakpoint here, and move the execution position to the next line
console.WriteLine("Foo");
return true;
}
In debug mode, you will be able to do that , not in release mode (because the compiler has detected the code was unreachable, and hasn't build it at all.
Related
I'm writing an Eclipse plugin that needs to specifically make use of Workspace, Projects, Packages, Compilation Units etc.
I already have a decent number of projects, packages, and compilation units in my workspace (not all related to my plugin though, but present nevertheless), which I would like to be able to use as a 'test dataset' for debugging.
When I click the toolbar icon of my plugin, I can print to the console the names of the projects returned by this statement:
IProject[] projects = ResourcesPlugin.getWorkspace().getRoot().getProjects();
However, when I launch the debugger, a new Eclipse IDE instance starts up with no projects visible in it anymore. While no project is visible, the projects array does list the project RemoteSystemTempFiles!
But this is completely useless for my debugging needs, as I need some good data set to step through during debugging.
Question: Is there any way to make my projects existing in the development instance of the IDE appear in the second, debugging instance also? Or, if not, can I somehow debug in the same IDE instance instead of starting a second one? I would hate to litter all my code with console-log messages - it's very tedious also to write them in the first place. Setting up the existing test data in the plugin's initialization code would also be way too much work, which I would like to avoid as well.
No you can't run or debug in the same instance. Eclipse will always start a new instance.
You will have to set up the test workspace to contain the data you need to test with.
I have web config transformations set up that work fine when I publish to something like Azure. But selecting between Release and Debug locally seems worthless if the web.config transformations don't actually get applied when running locally.
Is there any way to get these transformations to apply when I click "run"? If not, what's the point of having that dropdown? I'm genuinely curious, not asking rhetorically.
The idea for web.config transforms is that you have some settings that change between environments. For example, you might have a local development connection string, and you'll always use that when running/debugging locally. When you publish to your production server, though, you want to use your production DB. Debug vs. Release configurations at build time just change some settings in how your project is built (most commonly, how debug symbols are generated or what compiler optimizations are enabled), whereas web.config transforms are changing the content of what gets deployed (in web.config).
If you do want to apply the web.config transforms locally on F5, there are extensions that allow you to do so. Slow Cheetah is one such. However, in many cases, you probably don't need this as your web.config will stay mostly constant whenever you run locally.
Almost all IDEs have release and debug modes, in the debug mode, the code is compiled using debug flags and not so much optimization, i.e., some relation between the built program and the source code is kept, in this way you can run your code using a debugger, it is a tool that allows you to track and control the flow of execution of your application, for example the value stored in some variable in some situation in your code, this in order to expose semantic problems that your application may have, i.e., when your code is not actually doing what you expect it to be doing (most of the people does this using print statements everywhere at least once).
The release mode is aimed to produce an optimized version of your application, without debugging/profiling flags.
Notice that this have nothing to do with debug mode of web applications, where we set automated views to show more information when a run time error occurs, it just have to do with optimization or debugging of the actual program running underneath. So setting debug or release mode may not change whether a web application shows tracebacks or not, but it certainly changes the performance of the application running locally in your server.
Regards.
In our company we are developing a normal ASP.Net application.
Now we need to transfer the application to a cloud application that will run under Windows Azure.
So we will have two version of the application
Normal installation on IIS
Runs under Windows Azure
My question is that how to manage the TFS branches. Should I create two TFS branches foreach version and do each change 2 times or is there an alternative way to handle this problem?
Thank you in advance for you help.
We did one of the project like this, where two versions of the application (regular IIS deployment and Azure) have to be maintained in parallel. Although there were substantial differences between the two versions, we used one single code base. This worked out pretty good, I think we would have more problems if we decided to go with branches.
Few hints to make it easier to use one single code base accross legacy and Azure deployments:
1: Differences in behavior in the code is easy to do with dynamic check
if (RoleEnvironment.IsAvailable)
{
// Azure specific code
}
else
{
// normal IIS code
}
Any differences in UI could be done this way by hiding/unhiding elements from the page.
2: Create separate project and solution configurations for a) IIS production deployment, b) IIS debuging, c) Azure production and d) DevFabric. Use web.config transforms to get around any differnces in web.config.
3: For debugging under DevFabric the base version (i.e. non-transformed version) of web.config is used. I found it easier to make your base web.config to be used unmodified for DevFabric environment (i.e. the transform you would create for DevFabric would be empty). This makes debugging under DevFabric easy. The side effect is that it makes it impossible to debug under Callipso. As a workaround for Callipso problem, setup normal IIS on your dev box and use WebDeploy to publish your package built using IIS debug configuration to local IIS instance.
If the differences between the branches are small, consider using conditional compilation to switch between different platforms - this eliminates the need to branch and makes it easy to see when you're working on parts of the code that are branched. Similarly you can use abstract classes with a concrete implementation for each platform, which is a much cleaner approach than using #if on lots of small chunks of code.
If branching, then I'd use one of two approaches: if the differences are isolated, possibly consider refactoring the code to collect the differences into a small area of the codebase, and just branch that bit. Or insert a root level folder and branch there so that absolutely everything is branched.
When you make changes in one branch you will have to merge those changes across to the other branch, which is why I'd try to minimise the scope of the branches, to minimise the need to merge.
I just discovered (the hard way) that if you deploy your application to a device after doing a "Rebuild" or a "Clean -> Build" from Visual Studio your app is first uninstalled and then reinstalled resulting in the isolated storage files being wiped.
The Application Deployment Tool always seems to do uninstall - reinstall irrespective of whether it was an incremental build or not.
Has anybody found a workaround to this? Of course, the most obvious one is never to rebuild your application, but what if you accidentally do? Currently, I don't have all the generated files under source control, so if I were to try to build the app on another computer it would be a rebuild (maybe I will add all the generated junk into source control if no one has a workaround)
If I can suggest an alternative appraoch.. I think you will find it beneficial in other situations as well if you can introduce a little process to the generation of your test data so that it is easier to either a) restore or b) generate.
You could for example have a debug build only feature to upload/download the files on the device to a wcf service running locally on your PC (a simplified version of what Rongchaua did here).
Or, more work, if you are willing, but offering even more additional benefits would be to develop some automated testing capability into your app.. starting with generation of initial test data. Here's something you could look at to get started on that path.
Claus Konrad Blog: WP7: How to unit test a MVVM Light WP7-application
Granted these would take a bit of effort, but it's an approach that gives you some independence from manually generated test data, which in my experience invariably turns out to be a hassle at various times. And once solved, you find all sorts of reasons to thank yourself for doing it later.. whether it be saved time, or more robust testing because you can afford to be more aggresive with your test data/test execution and manage multiple test data configurations.
There is a a workaround:
open the solution configuration manager
next to build is a deploy column, uncheck your project
press F5
This will launch the app that is already on the device without overwriting it (and deleting its storage).
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.