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.
Related
I'm running tests in Visual Studio using "Test Explorer" with NUnit and a .runsettings file (specified by choosing the option in the GUI "Select Settings File")
My settings file (called mytests.runsettings) is:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<RunConfiguration>
<DisableAppDomain>True</DisableAppDomain>
</RunConfiguration>
<ForceListContent>true</ForceListContent>
<NUnit>
<DomainUsage>None</DomainUsage>
</NUnit>
</RunSettings>
I have verified that it is loading this file (verified by adding the framework node and setting it to a fake version, which then results in an error).
But no matter what I do, it doesn't run without an AppDomain!
Running from the command line does work:
nunit3-console.exe --domain=None --inprocess MyTests.dll
What do i need to do to get it to use that setting in NUnit?
I don't believe you can do that.
There is no recognized DomainUsage element under NUnit in the runsettings file. DomainUsage is an internally used property, which will be honored if set. But you can't set it that way. Your DomainUsage element is simply being ignored.
If the adapter received your DisableAppDomain setting, then it would set DomainUsage to None. However, I don't believe it is actually receiving it.
Point 2 requires some explanation. Note that I haven't worked on the adapter for a few years and I'm going from memory but here it is...
The DisableAppDomain setting was added to allow Visual Studio to force NUnit to try to run without using an AppDomain. The Test Explorer is supposed to set things up so that it's possible to run that way, i.e. by making sure everything is already available in the current domain.
In order to prevent misuse of the feature, I believe that Test Explorer always overrides any user-provided setting. Again, this is from memory of work that was done a few years ago, but it seems as if the results you are seeing validate it.
The rationale for this past decision was that Test Explorer is completely responsible for setting up the Process and AppDomain used to run the tests. The user has no way to impact that and neither does NUnit. Of course, when using the console runner, that's not the case - control is in the hands of the user.
Something else to investigate is why you feel the need to run without a test AppDomain being created. But that's probably another question. :-)
I'll ask some other folks who may have a better memory than I to look at this as well.
UPDATE:
#Terje, who maintains the adapter now, replied and confirmed that there is no way to set DomainUsage in the runsettings file or any other way we know of when running under the test adapter. The docs have been corrected to avoid the implicit suggestion that it's possible.
We believe, but have not confirmed experimentally, that TestExplorer creates it's own AppDomain whenever it uses this setting to suppress its creation by the test adapter.
This answer is a follow up to the answer from #charlie above, just need some more space here.
I've checked on the domains that are being created, based on whether the DisableAppDomain is set or not.
When the disable app domain is not set, the appdomain is created by NUnit with applicationbase and friendly name as shown below:
The NUnitCheckDomain is the test dll.
When the disable app domain is set, NUnit no longer sets its own domain, and you then see it runs under the testhost appdomain, which is the process that runs all tests:
So this seems to work the way it should and can.
Do you need it to run under some other app domain than one of these?
BTW: If I run the NUnitCheckDomain test assembly using the NUnit3 console, then it a) works when run directly b) crashes when used with the parameters you give above (domain=None and --inprocess) with not able to load NUnit.Framework. #charlie - Any reason this should not work the same using NUnit3-Console ?
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.
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 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.