We Keep Coding

Is there an option to deactivate style cop rule without making an "GlobalSuppressions.cs" file?

We use StyleCop Analyzer in our project. One of my tasks is to deactivate a few rules, but without creating a GlobalSuppressions.cs file.
I found solutions, but only with creating this file, so I'm confused.

To suppress a warning outside of GlobalSuppressions.cs, you can either:
Use comments (remember to restore the warnings out of the scope!)
#pragma warning disable IDE0052 // Remove unread private members
private readonly Object _obj;
#pragma warning restore IDE0052 // Remove unread private members
or use the SuppressMessage attribute in place
[SuppressMessage("Code Quality", "IDE0052:Remove unread private members", Justification = "<Pending>")]
private readonly Object _obj;
If you want to disable them globally, you can use an .editorconfig file at the root of your solution.
root = true
[*.{cs,vb}]
dotnet_diagnostic.IDE0052.severity = none
You can also configure a Ruleset file, but this is now deprecated.
In your csproj:
<PropertyGroup>
<CodeAnalysisRuleSet>File.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
and then create File.ruleset as your per your need. It looks roughly like
<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Microsoft Managed Recommended Rules" Description="These rules focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors. It is recommended to include this rule set in any custom rule set you create for your projects." ToolsVersion="10.0">
<Rules AnalyzerId="Microsoft.CodeQuality.Analyzers" RuleNamespace="Microsoft.CodeQuality.Analyzers">
<Rule Id="CA1056" Action="None" />
</Rules>
</Rules>
</RuleSet>
More details at https://learn.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#rule-sets

NUnit appSettings file attribute (linked config file) is not seen by ConfigurationManager in test

I have NUnit test (version 2.6.4) test. It uses ConfigurationManager.AppSettings["foo"] to retrive a configuration setting from the app.config file (which is in the test project). This is my App.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="bar.config">
<add key="thisSettingIsVisible" value="yes, indeed"/>
</appSettings>
</configuration>
and this is bar.config file:
<appSettings>
<add key="foo" value="this setting isn't visible"/>
</appSettings>
I'm using ReSharper 10 test runner to execute the test. bar.config file is copied to the bin/Debug directory. In fact, that configuration was working some time ago, but stopped. Any clues what can be wrong?
Now, I've figured out a workaround, but I'm not happy with this solution:
private static void InitializeAppSettings()
{
var exeAssembly = System.Reflection.Assembly.GetExecutingAssembly();
var assemblyName = exeAssembly.GetName().Name + ".dll";
var testDllFolder = new Uri(System.IO.Path.GetDirectoryName(exeAssembly.CodeBase)).LocalPath;
var openExeConfiguration = ConfigurationManager.OpenExeConfiguration(Path.Combine(testDllFolder, assemblyName));
foreach (var setting in openExeConfiguration.AppSettings.Settings.AllKeys)
{
ConfigurationManager.AppSettings[setting] = openExeConfiguration.AppSettings.Settings[setting].Value;
}
}
BTW. I can't abstract away ConfigurationManager usage form existing, legacy code.

I replicated your use case and found that my additional config worked in the context of an ASP.NET site but the additional appSetting was null in a test project until I changed the Copy to Output Directory property to Copy Always

If you use R# 10.0.0 or R# 10.0.1 - it is a known issue for such builds and it has been fixed in R# 10.0.2 build.

C# Project calling another Project failing with App.config

I have a solution with 2 projects. One project is a console app that you plug information into and it will provide data back. The second project creates multiple processes that call the first project by passing an argument. Up to this point everything is working.
I wanted to play around with being able to change the format the first project generates so I changed it's static format string to load from App.Config instead. When I run the first project by itself there is no issue and everything still works. After this change whenever the second project creates a process of the first project it fails with an ArgumentNullException and seems to not load the format string.
Here is my code for the second project that is calling the console application.
public static void Main(string[] args)
{
for (int i = 1; i < 10; i++)
{
Process EulerProblemN = CreateNewProcess(ExecutionPath, i.ToString());
EulerProblemN.Start();
string output = EulerProblemN.StandardOutput.ReadToEnd().Replace(Environment.NewLine, "");
Console.WriteLine(output);
EulerProblemN.WaitForExit();
}
Console.Read();
}
public static Process CreateNewProcess (string path, string argument)
{
Process eulersOutput = new Process();
eulersOutput.StartInfo.FileName = path;
eulersOutput.StartInfo.Arguments = argument;
eulersOutput.StartInfo.RedirectStandardOutput = true;
eulersOutput.StartInfo.UseShellExecute = false;
return eulersOutput;
}
In case it's relevant this is how I'm accessing the configuration in the first project:
private string AnswerFormat = ConfigurationManager.AppSettings["AnswerFormat"];
Contents of App.Config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="AnswerFormat" value="The answer to Problem {0} is {1}, the program took: {2} milliseconds to complete."/>
</appSettings>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
</configuration>
What is cause of this error? Does it have to do with how the second project calls the first?
EDIT:
First I tried to override the default env. config path as described here: Using ConfigurationManager to load config from an arbitrary location. I added that code to both projects. Unfortunately this didn't resolve the error so I moved a copy of app.config into both projects. The First project continues to run with no issues. I tested it and the second project successfully loads from its own app configuration, but when it calls .Start() on the process of the first project it is still failing with the same ArgumentNullException error.
It seems like Project 1 is not loading from the configuration file if called as a Process from project 2. Project 2 can see it's own config file and it's identical to the one in Project 1. Is this still a configuration file issue or could it be something else?

The App.config which is loaded is that of the project you run. the other project is effectively referenced as a class library and its App.config file will not be loaded. You'll need to place the setting in your first project's config file as well.

Replace #ifdefs in C# DLL

I have a C++ DLL which has #defines used like (these defines are automatically defined based on the build configuration, e.g. Debug, Release, etc)
#if defined(CONSTANT)
..
// Some code
#else
// Some other code
I need same functionality in C# dll.
Is it ok if I define some global constants in C# dll and use them
instead of defines?
e.g.
if(Globals.SomeConstant == SOMEVALUE)
// Do this
else
// Do smth else
Then when I want to ship the DLL I will in advance (probably as a default value during declaration) assign SOMEVALUE to Globals.SomeConstant - will this work this way? (Depending on which configuration I need).
I saw some similar questions but they weren't about DLLs.

You can use it similarly as in c++
You can define / undefine them in your source code or as a conditional compilation symbol. In visual studio this can be done using Solution Explorer - Properties - Build - conditional compilation symbols
However, nowadays people tend to use a configuration file for these constants. This way, you don't have to recompile your source code nor redistribute it to change the behaviour.
The most easy method is via visual studio solution explorer - properties - settings
You can add settings for most types. Booleans come closest to #define. Using an int can give you more than two possibilities. See the difficulties if you wanted to be able to use several values for a TimeSpan or an URI using #define.
The nice thing about using the settings is that a class is generated for you to easily access the settings.
Another method is to read the config file directly using the System.Configuration.ConfigurationManager class. This gives you more freedom about the format of the configuration. The disadvantage is that you have to convert the read values into proper types yourself, inclusive handling errors if the value can't be read.
Summarized: advantages of the config file method:
No need to change source files
No need to recompile
No need to re-install
only change the config file on those machines that need the change
improved type safety

My previous answer lead to a more questions than it answered. Hence I thought an example would help.
Suppose I have a DLL, called MyDll. It has a configuration setting that in really old times would have been defined using #define.
My C-synctax is a bit rusty, but it would look like:
#define UseAlternateGreeting
public class MyClass
{
public string GetGreeting()
{
#if defined UseAlternateGreeting
return "Hello World!";
#else
return "Here I am!";
#endif
}
}
Now suppose we have several programs that use this DLL. Program! wants to use the default setting. However Program2 wants to use the alternate setting. There is no way to solve this.
Besides if we want to change the value of the setting we have to recompile and redistribute everything to everyone.
Wouldn't it be easier if we could just edit a file with notepad to change the string?
Luckily Microsoft also saw the advantage of this. Over more than 10 years we have the idea of configuration files. Assemblies have a config file with the name of the application and the extension config. This file can easily be edited using any text editor by those who know what the configuration items mean.
If we replace the #define with an item in the config file the greeting could be changed to the alternate greeting without having to recompile and redistribute the whole program.
Luckily Visual Studio helps us a lot when creating the config file.
Preparations
Let Visual Studio Create a console application in a new Solution: name the program ConfigExample
Add a new Library to this application, name it MyDll
View the properties of MyDll
Add a Setting.
Name: MySetting,
Type: string,
Scope: application,
Value: Hello World! (without string quotes)
In project MyDll create a class MyClass
public class MyClass
{
public string GetText()
{
return Properties.Settings.Default.MySetting;
}
}
Go to project ConfigExample
Project Add reference to MyDll (via tab page solution)
Use the code in your main:
using MyDll;
static void Main(string[] args)
{
var obj = new MyClass();
var txt = obj.GetText();
Console.WriteLine(txt);
}
Compile and run, and you'll see the proper text displayed. If you go to the debug / bin directory of the program you'll find a text file ConfigExample.config. Open it in a text editor and you'll see... nothing abut hello world!
This means that your program is not really interested in a special setting, the setting that was default the time that MyDll was built may be used.
However, if you want to use a special setting,
In visual Studio, Go to project MyDll
open file app.config
a.o. you'll find the following
(to prevent the editor interfering with the formatting, I added an apostrophe to each line)
'</configSections>
'<applicationSettings>
'<MyDll.Properties.Settings>
'<setting name="MySetting" serializeAs="String">
'<value>Hello World!</value>
'</setting>
'</MyDll.Properties.Settings>
'</applicationSettings>
Copy paste this part to ConfigExample.Config
for all already distributed programs do this in the folder where the executable is (in your case: debug/bin)
for all ConfigExample programs that will be built in the future do this in visual studio in App.Config of the ConfigExample project.
The result will be as follows:
'<?xml version="1.0" encoding="utf-8" ?>
'<configuration>
' <configSections>
' <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="MyDll.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
' </sectionGroup>
' </configSections>
' <applicationSettings>
' <MyDll.Properties.Settings>
' <setting name="MySetting" serializeAs="String">
' <value>Hello World!</value>
' </setting>
' </MyDll.Properties.Settings>
' </applicationSettings>
'
' <startup>
' <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
' </startup>
'</configuration>
Now all we have to do is change the Hello World into an alternat greeting
' <MyDll.Properties.Settings>
' <setting name="MySetting" serializeAs="String">
' <value>Here I am!</value>
' </setting>
' </MyDll.Properties.Settings>
Run the program without building it and you'll see that the new value is used.
Advantages:
- It works with a lot of types that can be assigned from string - Type.IsAssignableFrom(typeof(string)). Visual Studio already supports a lot of types including TimeSpan and DateTime.
- You don't have to recompile your source code to change the value
- Several executables can use their own configuration setting: one program could use the original greeting, the other can use the alternate one
- If your program doesn't provide a value in the config file the default value is used.
- You don't have to read the configuration yourself.
- It is type safe: if you say it is a TimeSpan, then you have to do some serious typing to confuse it with for example an integer.
Well there is a lot more to be said about configuration, you can even have a configuration per user. But that's far outside your question about alternatives for plain C #define

Initialization Of Connection String In WinForm And In UserControl

See the Coding below:
**Application Config File**
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key ="Mystring" value ="server=MyServer;Initial Catalog
MyDataBase;uid=MYUID;pwd=MYPWD"/>
</appSettings>
</configuration>
**Connection Code:**
string connstr = ConfigurationManager.AppSettings["Mystring"];
SqlConnection con = new SqlConnection(connstr);
con.Open();
I have tested it at WinApplication and in Windows Control Library(UserControl) and found that the above code works in WinApplication and the same is not in Windows Control Library instead it throw exception like ” Connection string has not been Initialized”
If SQL assembly present in both VS application then Is it reasionable exception In Winows Control Library?.
What is the Solution?.

If you are using a test project, you need to add the settings (app.config file) there.
If you are debugging directly, DEVENV creates a sample app that host user control, you need to need to read the settings explicitly.
You can use preprocessor directives to differentiate whether user control debugging by DEVENV, or by hosting in under app.
Code like
#ifdef RunningUnderHost
// read app settings
#endif
RunningUnderHost can be defined over library, and not over app.