Develop Reference

How to enable FunctionName attribute on an azure function only if it is in a devvelopment environment?

I have an azure function written in C#. I want to enable a Http triggered Azure Function only if it is in a Development environment.
I tested this feature with using a pre-processor directive such as #if and i am able to show/hide an Azure function in the output window.
private const string HttpTestFn = "RunHttpTest";
#if DEBUG
[FunctionName(HttpTestFn)]
#endif
However, i want to extend this to work based on the Environment such as
#if Environment.IsDevelopment()
[FunctionName(HttpTestFn)]
#endif
How do i achieve this?
TIA!

This won't work
#if Environment.IsDevelopment()
You would create a specific build configuration for the dev environment, when deploying to that environment, you use the build configuration to build, package and deploy to that environment
So you keep the
#if DEBUG
[FunctionName(HttpTestFn)]
#endif
I am not sure what do you use to deploy your app to different environments, but will assume you are using some sort of a pipeline to build and deploy the app, so when building, you would use a different build parameters for development environment than for other.
For release you would use
dotnet build --configuration Release
but for your development environment you would use
dotnet build --configuration DEBUG
This way the version being deployed to dev won't have that function.
Another note, I would put the #if #endif at the start and end of the function file rather than just around the functionname attribute.

Disable EnableOptimizations on Debug mode

Can you tell me how to handle 'BundleConfig.cs' file's below line when we are working on debug mode ?
Because I need to ignore below line on debug mode.How can I do that ? Any help would be highly appreciated.
BundleTable.EnableOptimizations = true;

The easiest way is to use the #if Preprocessor directive
#if DEBUG
BundleTable.EnableOptimizations = false;
#else
BundleTable.EnableOptimizations = true;
#endif
If your app is running in debug mode, Visual Studio defines DEBUG for you. On the other hand, if your app is running in release, DEBUG will be undefined.
In order to check if it's a release version, you check for DEBUG to not be defined
#if !DEBUG
BundleTable.EnableOptimizations = true;
#endif
PS: For obvious reasons, there is no RELEASE flag.

Execute local R script via R.NET

I'm looking to use R.NET to execute an existing R script but haven't had success. Is this actually possible? I've run the example code successfully, so my basic setup is ok.
My code looks like the following:
static void RTest()
{
var envPath = Environment.GetEnvironmentVariable("PATH");
var rBinPath = System.Environment.Is64BitProcess ? #"C:\Program Files\R\R-3.0.1\bin\x64" : #"C:\Program Files\R\R-3.0.1\bin\i386";
Environment.SetEnvironmentVariable("PATH", envPath + Path.PathSeparator + rBinPath);
using( var engine = REngine.CreateInstance("RDotNet") )
{
engine.Initialize();
using( var fs = File.OpenRead(#"C:\R-scripts\r-test.R") )
{
engine.Evaluate(fs);
}
}
}
Which I'm running in a console app for testing (eventually I want to have it run server-side in a web app).
The r-test.R script works when run in RStudio so there's no problem there and should result in writing a csv file to disk. I do see some 'Loading required package' messages being output to the console so something is working but the resultant csv file does not appear.

As indicated in response to this post in the R.NET discussions, you can use engine.Evaluate(#"source('c:/path/to/r-test.R')"). Although a lot depends on the content of your script of course, it should work. That said your code looks like it should work as well, though I have not tried your approach.
It is possible that R.NET chokes on some particular R statement within your script. If you have visual studio it should be possible for you to attach to the process if you use R.NET compiled from source with debug symbols. If you have Visual Studio this is the easiest option; MonoDevelop / Xamarin studio is also an option, though a bit more involved. This should help you identify the troublesome line.
Hope this helps

SQLite.Interop.dll locked after running Visual Studio 2012 Unit Test Framework tests

Visual Studio 2012
SQLite 1.0.82.0 (from nuget)
I am trying to use the "Run All" command in the "Test Explorer"
The following error happens after you run the test once ... after that it will not build anymore, until you restart visual studio
Here is the build error
The Process cannot access the file 'SQLite.Interop.dll' because it is
being used by another process
here is the code
using System.Data.SQLite;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace Test.Sqlite
{
[TestClass]
public class Test_Sqlite_Locking
{
[TestMethod]
public void can_create_table()
{
using(var fact = new SQLiteFactory())
using (var conn = fact.CreateConnection())
{
conn.ConnectionString = "Data Source=:memory:;Version=3;New=True;";
conn.Open();
//conn.Close();
}
//SQLiteConnection.ClearAllPools();
//GC.Collect();
}
}
}
I have tried, closing connection, calling ClearAllPools, GC.Collect, and creating the SQLiteConnection directly (instead of the Factory) ... still same issue
This DOES work if you DEBUG ALL TESTS ... but it is when you just Run the tests that this seems to lock it up

I could not find that option in VS2012 (at least not for standard unit tests), therefore I came up with another solution:
The problem you are facing comes from the fact that the unit test runner remains loaded so that repeated test runs are faster. Since SQLite.Interop.dll will probably not change too often, I changed the CopyToOutputDirectory option to PreserveNewest rather than the default Always.
You can do this by opening the properties (F4) view and selecting the SQLite.Interop.dll file in your solution. The only time this will probably still lock up is when you upgrade to a newer version of SQLite and restarting VS2012 then works OK for me.

I worked around this by using the following as a pre-build event on the affected test projects:
for 64-bit:
taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"
or for 32-bit:
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
This silently kills the execution engine before building the test project. The /FI "MEMUSAGE gt 1" stops the command (and therefore the build) from failing if the execution engine isn't running.

Try this:
In VS.NET, click on Tools \ Options
When the dialog appears, click on "Test Tools"
Click on "Test Execution"
Uncheck the box "Keep test execution engine running between tests"
Click OK and restart VS.NET
You should be able run SQLite based tests now without having to restart.

In Visual Studio 2013 - Go to "Test > Test Settings > keep Test Execution Engine Runing" and uncheck it! Works for me.

The workaround provided by Philipp Aumayr (set CopyToOutputDirectory option to PreserveNewest rather than the default Always) works for most scenarios, but not all, unfortunately. As other questions on SO point out, the fact that vstest.executionengine does not terminate is a common issue in VS2012 - worse, Microsoft developers treat this as a feature and by design. The option to prevent this behavior existed in VS2010 but has been removed in VS2012.
If you too have a problem with this "improvement" then please vote on the Microsoft Connect support issue vstest.executionengine.x86.exe (32 bit) - Not Closing (affects both x86 and x64 despite the title).

I know this question is old, but I had this problem and some of the answers here sparked an idea. One of the first problems I encountered when trying to build unit/integration tests around SQLite was that MSTest (which we use for scripted builds) wasn't deploying all of the necessary dependencies to the test run's "Out" directory before running the test, so the tests failed. The best way I found to solve this problem was to add these attributes to my test class:
[TestClass]
**[DeploymentItem("System.Data.SQLite.dll")]
[DeploymentItem("x86\\SQLite.Interop.Dll")]**
public class TestClass
This appears to also solve this issue...I'm guessing this causes VSTest to load a different copy of these dependencies so that VSBuild can still do what it will with the copy in your normal /bin/ directory.

Also make sure that your Database is installed to the correct folder
SQLite Connection Strings
Data adapter that you may want to try as well using SQL Lite
Using SQLitew with .NET
SQLiteConnectionStringBuilder builder = new SQLiteConnectionStringBuilder();
builder.FailIfMissing = true;
builder.DataSource = "Insert the fully qualified path to your sqlite db";
SQLiteConnection connection = new SQLiteConnection(builder.ConnectionString);
try
{
connection.Open();
}
catch(SqlException exp)
{
// Log what you need from here.
throw new InvalidOperationException("Whatever exception you want to throw", exp);
}
Read this Article to see if it helps to correct your issue as well
System.Data.SQLite.View Ticket

Try disposing of the connection as below. It worked fine for me.
private void Dispose(bool disposing)
{
if (_disposed) return;
if (disposing)
{
if (_dbConnection != null)
{
_dbConnection.Cancel();
_dbConnection.Close();
_dbConnection.Dispose();
}
}
_disposed = true;
}

Running different code in debug and release settings visual studio

Is it possible in C# to do run specific lines codes in debug setting and other in say release settings.
if #debug
//run some lines of code
else
// run different lines of code

You can do something like:
#if DEBUG
// Debug Code
#else
// Release Code
#endif
I use that in WCF services to run it as a console app in debug, but as a Windows Service in release
HTH,
Rupert.

Read this blog post If You’re Using “#if DEBUG”, You’re Doing it Wrong, the author suggests using System.Diagnostics.ConditionalAttribute:
[Conditional("DEBUG")]
private static void DebugMethod()
{
// Debugging code
}