Develop Reference

global usings and .NET Standard 2.0

I recently recognized that I can use the C# 10 feature file-scoped namespaces in .NET Standard 2.0 projects as well by setting <LangVersion>10</LangVersion> in the csproj file.
However, global usings don't work that way, I'm getting compiler errors due to missing using statements.
Are there any tweaks so that I can use global usings in a .NET Standard 2.0 library as well?

I'm not sure why it doesn't work with a separated .cs file. However, a workaround that works is using the MSBuild syntax. In your .csproj you can add the following:
<ItemGroup>
<Using Include="System.Linq" />
</ItemGroup>
There are some keywords you can use - like Alias or Static -, as you would do in a normal .cs file.
<ItemGroup>
<Using Include="Test.Namespace" Alias="Domain" />
</ItemGroup>
And then in your code, you can do the following:
namespace Test.Namespace
{
public class TestClass {}
}
namespace Another.Namespace
{
new Domain.TestClass();
}
If it helps, I found this information in the following blog post.

Having issues unit testing internal class in c# [duplicate]

I'm trying to figure out if I should start using more of internal access modifier.
I know that if we use internal and set the assembly variable InternalsVisibleTo, we can test functions that we don't want to declare public from the testing project.
This makes me think that I should just always use internal because at least each project (should?) have its own testing project.
Why shouldn't one do this? When should one use private?

Internal classes need to be tested and there is an assembly attribute:
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("MyTests")]
Add this to the project info file, e.g. Properties\AssemblyInfo.cs, for the project under test. In this case "MyTests" is the test project.

Adding to Eric's answer, you can also configure this in the csproj file:
<ItemGroup>
<AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
<_Parameter1>MyTests</_Parameter1>
</AssemblyAttribute>
</ItemGroup>
Or if you have one test project per project to be tested, you could do something like this in your Directory.Build.props file:
<ItemGroup>
<AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
<_Parameter1>$(MSBuildProjectName).Test</_Parameter1>
</AssemblyAttribute>
</ItemGroup>
See: https://stackoverflow.com/a/49978185/1678053
Example: https://github.com/gldraphael/evlog/blob/master/Directory.Build.props#L5-L12

If you want to test private methods, have a look at PrivateObject and PrivateType in the Microsoft.VisualStudio.TestTools.UnitTesting namespace. They offer easy to use wrappers around the necessary reflection code.
Docs:
PrivateType, PrivateObject
For VS2017 & 2019, you can find these by downloading the MSTest.TestFramework nuget

starting from .Net 5, you can use also this syntax in the csproj of the project being tested:
<ItemGroup>
<InternalsVisibleTo Include="MyProject.Tests" />
</ItemGroup>

I'm using .NET Core 3.1.101 and the .csproj additions that worked for me were:
<PropertyGroup>
<!-- Explicitly generate Assembly Info -->
<GenerateAssemblyInfo>true</GenerateAssemblyInfo>
</PropertyGroup>
<ItemGroup>
<AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
<_Parameter1>MyProject.Tests</_Parameter1>
</AssemblyAttribute>
</ItemGroup>

You can use private as well and you can call private methods with reflection. If you're using Visual Studio Team Suite it has some nice functionality that will generate a proxy to call your private methods for you. Here's a code project article that demonstrates how you can do the work yourself to unit test private and protected methods:
http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx
In terms of which access modifier you should use, my general rule of thumb is start with private and escalate as needed. That way you will expose as little of the internal details of your class as are truly needed and it helps keep the implementation details hidden, as they should be.

Keep using private by default. If a member shouldn't be exposed beyond that type, it shouldn't be exposed beyond that type, even to within the same project. This keeps things safer and tidier - when you're using the object, it's clearer which methods you're meant to be able to use.
Having said that, I think it's reasonable to make naturally-private methods internal for test purposes sometimes. I prefer that to using reflection, which is refactoring-unfriendly.
One thing to consider might be a "ForTest" suffix:
internal void DoThisForTest(string name)
{
DoThis(name);
}
private void DoThis(string name)
{
// Real implementation
}
Then when you're using the class within the same project, it's obvious (now and in the future) that you shouldn't really be using this method - it's only there for test purposes. This is a bit hacky, and not something I do myself, but it's at least worth consideration.

For .NET core you can add the attribute to the namespace as
[assembly: InternalsVisibleTo("MyUnitTestsAssemblyName")].
e.g. Something like
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("Applications.ExampleApp.Tests")]
namespace Applications.ExampleApp
internal sealed class ASampleClass : IDisposable
{
private const string ApiVersionPath = #"api/v1/";
......
......
......
}
}

In .NET Core 2.2, add this line to your Program.cs:
using ...
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("MyAssembly.Unit.Tests")]
namespace
{
...

Add InternalsVisibleTo.cs file to project's root folder where .csproj file present.
Content of InternalsVisibleTo.cs should be following
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("AssemblyName.WhichNeedAccess.Example.UnitTests")]

How to include required reference for project in it's release .dll

In my solution I have a project "commons" and project has reference like SpecFlow.CustomPlugin. When I build the project Com.Org.Commons.dll will get generated.
But when I refer this .dll file to another project (please look into attached image solution structure
)
"SFP" which has class NUnitPropertyGenerator.cs also need reference of SpecFlow.CustomPlugin which is already included in commons project.
I build the project commons and Com.Org.Commons.dll will get generated. But when I include the Com.Org.Commons.dll into SFP project below code gives me error and it doesn't refer to Com.Org.Commons.dll.
using TechTalk.SpecFlow.Generator.Plugins;
using TechTalk.SpecFlow.Generator.UnitTestProvider;
using TechTalk.SpecFlow.Infrastructure;
[assembly: GeneratorPlugin(typeof(Com.Org.SFP.CustomNUnitProperties.SpecFlow.NUnitPropertyGenerator))]
namespace Com.Org.SFP.CustomNUnitProperties.SpecFlow
{
public class NUnitPropertyGenerator : IGeneratorPlugin
{
public void Initialize(GeneratorPluginEvents generatorPluginEvents, GeneratorPluginParameters generatorPluginParameters)
{
generatorPluginEvents.CustomizeDependencies += (sender, args) =>
{
args.ObjectContainer.RegisterTypeAs<MasterProvider, IUnitTestGeneratorProvider>();
};
}
}
}
I thought TechTalk.SpecFlow will get refered if I include Com.Org.Commons.dll in SFP project which internally referes SpecFlow.CustomPlugin package.
Expected result should be:
SFP project should successfully build after including the Com.Org.Commons.dll and should resolve the code error which are related to TechTalk.SpecFlow. Logically both the project required SpecFlow.CustomPlugin package but as I am seperated out the details implementation to commons project and considering common project has a reference package included in dependencies I should be able to resolve the error in SFP project after referencing the Com.Org.Commons.dll in SFP project.
Please find .csproj file content
commons.csproj (https://gist.github.com/gittadesushil/100df50d4de72d61a9d57aa08c82cada)
SFP.csproj (https://gist.github.com/gittadesushil/dda1af31b5351f6ef9c71e44e2ceccda)

If you need to use the namespaces/classes defined in SpecFlow.CustomPlugin DLL, you will need to add a reference to that DLL directly in all projects where you are using its classes directly in code. For e.g., TechTalk.SpecFlow.Infrastructure looks like a namespace from SpecFlow.CustomPlugin that's being used in SFP. In this case SFP needs to have a reference to SpecFlow.CustomPlugin
If you were not using TechTalk.SpecFlow.Infrastructure directly in SFP then all you would need to do was to ensure that the CopyLocal property of the SpecFlow.CustomPlugins reference in commons was set to true.

You are using a normal Reference (https://gist.github.com/gittadesushil/dda1af31b5351f6ef9c71e44e2ceccda#file-sfp-csproj-L25) and not a ProjectReference.
correct would be
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net45</TargetFramework>
<RootNamespace>Com.Org.SFP.CustomNUnitProperties.SpecFlow</RootNamespace>
<AssemblyName>Com.Org.SFP.CustomNUnitProperties.SpecFlow.2.4.SpecFlowPlugin</AssemblyName>
<PackageId>$(AssemblyName)</PackageId>
<Description>$(PackageId)</Description>
<OutputPath>$(SolutionDir)Output\</OutputPath>
<DocumentationFile></DocumentationFile>
<IsTool>true</IsTool>
<BuildOutputTargetFolder>tools\SpecFlowPlugin.2-4</BuildOutputTargetFolder>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
<GenerateSerializationAssemblies>Auto</GenerateSerializationAssemblies>
<WarningLevel>0</WarningLevel>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="Com.Org.Commons" />
</ItemGroup>
</Project>
Normal References don't look at the dependency graph.

The type 'MySqlConnection' exists in both 'MySql.Data Issue

I have Referenced MySql.Data on one project and Other project referenced nuget package which also referenced MySqlConnector inside of it. projects has dependency .
when i compile application im getting this error
This is application hierarchy
is there any way to avoid this? or did i do anything wrong when referencing packages?
Thanks
UPDATE
this is the same namespaces from difference libs
UPDATE 2
This is the sample repo which reproduced same issue

In NET.Framework projects you can go to the reference properties and set an alias for assembly. Net core projects doesn't fully support yet aliases for assemblies. But there is a workaround to use aliases in .net core. Edit your csproj file like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
...
<Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition="'%(FileName)' == 'MySqlConnector'">
<Aliases>MySqlConnectorAlias</Aliases>
</ReferencePath>
</ItemGroup>
</Target>
...
</Project>
then in your cs file before all usings:
extern alias MySqlConnectorAlias;
then you can reference to you type from MySqlConnector like this:
MySqlConnectorAlias::MySql.Data.MySqlClient.MySqlConnection

It will work If you remove mysql.data reference from Your project/references.
Hope it will work for you. for me it was worked. My project is ASP.NET Core Framework. Created project in VS2017 and opening in VS2019 at that time it introduced.

Mono / MonoDevelop: Get solution version at runtime

I am looking to retrieve the application version (essentially the <ReleaseVersion> property in the solution file) at runtime. How does one access this via code?

The standard way of setting the application version in .NET (and therefore presumably MONO) is to use the AssemblyVersion attribute. This is normally specified in the AssemblyInfo.cs file, but can be specified in other files, as is shown below.
To get the version at runtime, you can use the AssemblyName.Version property. The following is a slightly modified version of the code from the given link:
using System;
using System.Reflection;
[assembly:AssemblyVersion("1.1.0.0")]
class Example
{
static void Main()
{
Console.WriteLine("The version of the currently executing assembly is: {0}",
Assembly.GetExecutingAssembly().GetName().Version);
}
}
When compiled and run, it produces this:
The version of the currently executing assembly is: 1.1.0.0
The above was tested on both .NET (Visual Studio 2010), and Mono 3.0 (compiled using mcs from the command line, not Mono Develop).

have you tried using the suggestions in this forum --> get current version

It's an ugly hack, but you can utilise the BeforeBuild target to write that property to a file, which you then promptly include as an embedded resource. In your *.csproj file:
<ItemGroup>
<EmbeddedResource Include="release-version.txt" />
</ItemGroup>
<!-- .... -->
<Target Name="BeforeBuild">
<Exec WorkingDirectory="$(ProjectDir)" Command="echo $(ReleaseVersion) >release-version.txt" />
</Target>
....then in your C&sharp; code, you could create a property like this:
public static string Version {
get {
using (StreamReader resourceReader = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream("SBRL.GlidingSquirrel.release-version.txt")))
{
return resourceReader.ReadToEnd().Trim();
}
}
}
This should work on all major operating systems. Don't forget:
To add using System.Reflection; to the top of your file if you haven't already
To add the release-version.txt file to your version control's ignore list (e.g. .gitignore, etc.)