I'm aware you can include directives to compile and run different code based on whether you're in debug or release mode. Can you do the same sort of thing when you build the project for distribution?
I ask because I've just submitted and had approved an app update which points to a web service on our test server rather than live!
Yes, you sure can.
In MonoDevelop under Project Options->Compiler->Define Symbols, choose the appropriate build configuration (AppStore), and you can make a new variable such as PRODUCTION.
You can then use:
#if PRODUCTION
#endif
Throughout your code.
Related
I have a library that will be built and published as a nuget package in release mode.
However for debugging purposes it is useful to capture stacktraces at various points.
Capturing a stack trace is relatively expensive, and I don't want to do it in release. However neither do I want to force everyone to replace my nuget package with the debug version when they want to debug their code.
Is there a way to check if the executable that a dll is running in was compiled with debug or release? In other words even though my nuget package was compiled with release, I want to run different code depending on whether or not the executable that my library is used by was built in release or debug?
The lines below appear to be in conflict with each other:
Is there a way to check if the executable that a dll is running in was
compiled with debug or release? In other words even though my nuget
package was compiled with release, I want to run different code
Usually it is possible to do something similar to what you are after by using pre-processor directives. This would allow your program to execute different paths according to for instance, the name of the configuration used to build the project:
#if debug
//Log
#endif
However, you seem to be after something different. It seems that you want to change behaviour but keeping the same build (release in both cases).
To cater for this, it might be easier to have a flag, say verbose which is false by default and when enabled, it logs the extra information. This would allow you to keep the same build mechanism but be able to log more information accordingly.
Edit: As per your comments, what I mean is something like this:
In your code that calls the nuget, you would have something like so:
#if DEBUG
var x = new NugetInstance(verbose:true...);
#else
var x = new NugetInstance(verbose:false...);
#endif
I have a test and production web server. My project has a piece of code that I would like in place on the test server, but not in place on the production server.
#if (DEBUG) doesn't work, because I prefer both to be published in RELEASE mode.
Is there any way to set up a preprocessor directive based on which web Publish profile is being used?
The easiest way to accomplish this is to create separate build configurations for each of the environments you need to publish to. You can clone your new build configurations from Release. Then, in the project settings, enter the name of your build configuration in the Conditional compilation symbols box.
So, for example, we have a Stage build configuration which is identical to Release except it defines the STAGE compiler constant. Then, in the code, you can use #if (STAGE) checks.
If you are like me wondering where MS moved everything, on VS2022, here it is:
We have a C# desktop application which we run for clients on various servers on a software as a service model. We are still on dot net framework 2.
The software has a architecture in which we have an independent application to catch external data thrown by some server. Then an application to make calculations based on it. Also one more application on which the client sees the output. The link between the 3 applications is another application which communicates with the DB.
The 4 solutions are on a SVN for sourcecontrol. But the release management is still manual and the patches are made manually by checking the log and including the dlls, pdbs, xml. etc for the projects for which the code has changed.
There is no assembly versioning implemented and the patch or release management is just done in the dark.
I want to know what is the industry practice for generating automatic patches from the code. Also I want a patch for each revision in the SVN. Also is assembly versioning helpful in this?
I have read much about continuous integration but it fails because we do not have unit tests and other fancy code to moniter the correctness of code.
The only thing at this time I would be interested is to implement a way to make patches which can be applied and removed easily. Also I want to know a way to determine the way we can monitor which release is at which level(or what patches have been applied) by some automated way rather than maintaining a log manually.
We use a build script which creates a SvnVersion.cs file containing the last commited revision. This file is placed in the root of the solution, and then added to all projects in the solution (but added as a link, not copied).
The template for the file (SvnVersion.Template.cs) looks like this:
using System.Reflection;
[assembly: AssemblyVersion("1.0.0.$WCREV$")]
[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]
And we simply use TortoiseSVN to fill these placeholders in a batch script:
type "%TRUNKPATH%SvnVersion.Template.cs" > "%TRUNKPATH%\SvnVersion.tmp"
SubWcRev "%TRUNKPATH%\" "%TRUNKPATH%SvnVersion.tmp" "%TRUNKPATH%SvnVersion.cs" -f
IF ERRORLEVEL 1 GOTO ERROR
DEL "%TRUNKPATH%SvnVersion.tmp"
If you don't use TortoiseSVN, there are other ways to get this info in the file.
You will also need to remove this same information from your AssemblyInfo.cs files or you'll get a compile error. Also, to speed up Debug builds, this is only executed in Release builds (and in Debug builds only if the file doesn't initially exists, like after a fresh checkout).
I am attempting to make it so that we can have our application to behave differently based on the presence of a preprocessor directive. I've read that you can create build configurations to define different preprocessor directives based on which build you do. Well, I am not seeing anything in Visual Studio to do this.. I know how to do it from the command line, but not how to do it within the automated environment of VS 2008.
Can someone tell me how to create a new build configuration which has preprocessor directives set in it?
Also, not sure if it has anything to do with it, but our project is an ASP.Net website
I do not even see a way to control the
DEBUG symbol, and it is an ASP.Net
website
Ok, there's the problem. The ASP.net web site option gives you a lot less control over builds, etc as it doesn't even use a project file.
If it is at all feasible for you to switch, switch over to an ASP.net web application. A web app will behave much more like a typical C# project (you have a project file, and the contents of the csproj file control what is in the app instead of just the directory structure, etc.
After you have converted, you should see the options that you are expecting.
Here's a link with directions for converting: How To Convert ASP.NET Website to ASP.NET Web Application
If you right-click the project and select "Properties", then select the Build tab, you can enter custom compilation symbols in "Conditional compilation symbols".
For example, if your code looks like this:
#if DEBUG
// do something
#else
// do something else
#end
You can set "DEBUG" as a Conditional compilation symbol.
You can set different values for different build configurations, by changing the "Configuration" drop-down.
In VS2008 (and earlier if I'm not mistaking) I have dropdown that lets me choose between Debug and Release mode. All well.
When I switch VS to Release, the debug attribute in my web.config files isn't set to false at all though.
Is this the way it is supposed to be? I am bound to forget to set it to the correct value on deploying.. What measures should I take to make sure this is working like it should?
This is one solution to this problem:
http://blog.aggregatedintelligence.com/2009/04/aspnet-never-again-fear-publishing-your.html
Well your web.config would probably be different for debug and release (connection string, passwords, etc...) but if it's not, look at a postbuild event which would copy over a different file.
Also check this blog post from Scott Guthrie.
Changing release mode will not change web.config, however when you build your web app, it will build the dll for only C# files in release mode where else your web.config's debug on/off is used by IIS to build debug/release version of ASPX markup files.
The build flavour just affects how the code is compiled, it does not affect your configuration files. So yes, to answer your question, this is how it is supposd to be.
The element is a good solution if you have access to the machine.config of your server, which hosts only production applications.
I usually modify the web.config file when generating the deployed files as part of the automated build process. For example web deployment projects can perform web.config section replacement. There are a number of reasons I don't like web deployment projects and I tend to do it with a simple VBS file that modifies the file using MSXML.
The answer you selected from Bobby is not correct. Visual Studio builds the files for you in release while you are in VStudio.
IIS compiles the code at startup with that setting when you deploy. Not the bin directory, but the App_Code and the code behind files.
You should precompile your app before deployment which will compile your code behinds and App_Code dir into dlls in the bin directory.
The deployment tools automatically switch that setting if you set the deployment tool to Release
I use web deployment projects. http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx