Develop Reference

Do repeated calls to AddHttpClient overwrite each other?

I have one NuGet package that has code like this in it:
services.AddHttpClient("CompanyStandardClient").AddCompanyAuthenticationHeaders();
And another Nuget project with code like this in it:
services.AddHttpClient("CompanyStandardClient").AddCompanyHeaderPropagation();
Basically, one NuGet sets up my company's authentication, and another sets up the company's header propagation.
I usually would do this code like this:
services.AddHttpClient("CompanyStandardClient").AddCompanyAuthenticationHeaders().AddCompanyHeaderPropagation()
I am worried that if I do them separate, only one will be in effect. I looked at the code on GitHub and it returns a newed DefaultHttpClientBuilder for each call.
return new DefaultHttpClientBuilder(services, name);
But I am not sure if this means that the previous entry was overwritten.
Can the same named client be "added" separately? Or will it overwrite?

I think it can be done for the same named client based on the internal comments here.
// See comments on HttpClientMappingRegistry.
private static void ReserveClient(IHttpClientBuilder builder, Type type, string name, bool validateSingleType)
{
var registry = (HttpClientMappingRegistry)builder.Services.Single(sd => sd.ServiceType == typeof(HttpClientMappingRegistry)).ImplementationInstance;
Debug.Assert(registry != null);
// Check for same name registered to two types. This won't work because we rely on named options for the configuration.
if (registry.NamedClientRegistrations.TryGetValue(name, out Type otherType) &&
// Allow using the same name with multiple types in some cases (see callers).
validateSingleType &&
// Allow registering the same name twice to the same type.
type != otherType)
{
string message =
$"The HttpClient factory already has a registered client with the name '{name}', bound to the type '{otherType.FullName}'. " +
$"Client names are computed based on the type name without considering the namespace ('{otherType.Name}'). " +
$"Use an overload of AddHttpClient that accepts a string and provide a unique name to resolve the conflict.";
throw new InvalidOperationException(message);
}
if (validateSingleType)
{
registry.NamedClientRegistrations[name] = type;
}
}
Source
The client options configurations will aggregate to a single option.

Inversion of Control and Choices

I am trying to use Inversion of Control correctly. My app is working fine. I am using Unity as the IoC container. However, I think I am going wrong when there is a choice on which concrete class to use.
In this example, I have a class that gets data from a specific data source. Depending on the file type, I call a data accessor class.
This service class checks the type, does a switch, and then selects which concrete class to use.
However, it seems I am breaking the IoC principles here, by 'newing' something in the class. I no longer inject into this service class, because at this point, I haven't decided which file type I'm working with. So I had to comment out the 'injection', and rather hard code it.
Here's a code extract.
public class DataService : IDataService
{
IFileReader _fileReader;
public DataService(IFileReader fileReader)
{
// _fileReader = fileReader;
}
/// <summary>
/// Returns reporting data based on a group of export files.
/// </summary>
/// <param name="files">A list of files to analyse</param>
/// <returns></returns>
private List<RawFileData> GetRawData(string[] files)
{
foreach (var file in files)
{
// validate files exists.
switch (GetFileType(Path.GetFileName(file)))
{
case "CSV":
{
fileIsOK = true;
_fileReader = new CSVileConnector();
break;
}
case "TXT":
{
fileIsOK = true;
_fileReader = new TXTFileConnector();
break;
}
default:
break;
}
if (fileIsOK)
{
var finedata = _fileReader.ReadData(file);
data.Add(new RawFileData
{
DataItems = finedata,
FileName = file
});
}
}
return data;
}
Is this the right way to handle this type of situation? Where, on class creation, I'm not sure which child class to 'depend' on? And then decide it in logic, and new up the correct Concrete class?

One improvement could be to separate the choosing of the reader from the reading itself--a private method called IFileReader _getDataReader(string filename). So in your foreach loop you say var reader = _getDataReader(filename);. There's no good reason for the reader to be a private property in your class since it isn't constructed, can change continuously, and the scope of its use is limited to GetRawData. What you could consider injecting through the constructor is a class with GetDataReader(string) in its interface definition. That itself could hold a private Dictionary<string, Type> which would have as its keys file extensions and then the reader of that file as the value. You could even configure that in your app.config if yau wanted. That's known as the Service Locator pattern.
There are good arguments that this is actually an anti-pattern for various reasons. It might also be argued that you're over thinking it--since you only have two choices and it's easy to read this way--but separating the choosing of the reader from the reading itself at least puts you in a place where it's easier to change if you need.

C# Discord Bot - get Userinput on a command parameter

I want to teach my DiscordBot how to deal with a Input after writing the command.
I create the Command this way:
private void CreateCommand(string commandName, string parameterName, ParameterType parameterType , string commandValue) // Register this command by the name and the answer value
{
commands.CreateCommand(commandName).Parameter(parameterName, parameterType).Do(async (e) =>
{
await e.Channel.SendMessage(commandValue); // Bots answer
});
}
I use this method to short my Code of the next method:
private void Add(string commandName, string commandValue, string commandDescription) // Add a simple command to the List
{
singleCommandList.Add(new Tuple<string, string, string>(commandName, commandValue, commandDescription));
}
private void Add(string commandName, string parameterName, ParameterType parameterType, string commandValue, string commandDescription) // Add commands with Parameters to the List
{
parameterCommandList.Add(new Tuple<string, string, ParameterType, string, string>(commandName, parameterName, parameterType, commandValue, commandDescription));
}
And this is the method filling my CommandList
private void FillCommandList() // Add all the commands to the List
{
Add("test", "success", "test"); // simple Command
Add("search", "onlineSearch", ParameterType.Multiple, Search("text to look for"), "Google it");
}
My Problem is that I do not know, how to fill the Parameter of the method Search(). What would I have to pass in there? Something with e.User ..?

I have created my own Discord.Net bot using this unofficial Discord C# Wrapper:
An unofficial .NET API Wrapper for the Discord client
Their Discord Server
The examples given in the documentation are not always up to date, since they made a huge and code breaking rewrite of their API but it is really well done using the async patterns.
That should give you more examples and ideas on how to continue with your idea.
Make sure using the 1.0 version - the dev branch. (as of now)
Everything else is described on their Github. If you still need answers join their discord. They are very helpful.

Use e.GetArg("parameterName") to get the parameter named "parameterName". This works if the ParameterType is Optional or Required.
If your ParameterType is Multiple, try:
string search = string.Join(" ", e.Args)
to get the entire "onlineSearch" parameter.

HelpVerbOption is not working - Command Line Parser C#

I have a class:
class Options
{
// Remainder omitted (verb1, verb2, verb3)
[HelpVerbOption]
public string GetUsage(string verb)
{
return HelpText.AutoBuild(this, verb);
}
}
The docs say:
[...] The parser will pass null to master class GetUsage(string) also if
the user requested the help index with:
$ git help
or the verb command if the user requested explicitly
instructions on how to use a particular verb:
$ git help commit
[...]
Then, I typed MyApp.exe help verb1, but I could see only the base help (that looked like I typed the wrong verb, or help verb, or something). Rather, I expect it to show the help message related to specified verb. Why isn't it working properly?

For me it works using the mentioned approach, but only if I call my app without the --help-option (for instance MyApp batch). When I use MyApp --help batch the behaviour is as described by you.
However we can´t seem to get the same to work for the help-option.
EDIT: I managed to get this working by modifying the code of Commandline.Parser.cs with the following:
private bool TryParseHelpVerb(string[] args, object options, Pair<MethodInfo, HelpVerbOptionAttribute> helpInfo, OptionMap optionMap)
{
var helpWriter = _settings.HelpWriter;
if (helpInfo != null && helpWriter != null)
{
if (string.Compare(args[0], helpInfo.Right.LongName, GetStringComparison(_settings)) == 0)
{
// User explicitly requested help
var verb = args.FirstOrDefault(); // <----- change this to args[1];
if (verb != null)
{
var verbOption = optionMap[verb];
if (verbOption != null)
{
if (verbOption.GetValue(options) == null)
{
// We need to create an instance also to render help
verbOption.CreateInstance(options);
}
}
}
DisplayHelpVerbText(options, helpInfo, verb);
return true;
}
}
return false;
}
The problem appears at the line
var verb = args.FirstOrDefault();
As the very first argument (args[0]) is interpreteted as the verb or better the action (as described in the docs) verb will allways be help here. So we replace this by args[1] which contains the actual verb, for example commit.
EDIT2: To make this work for --help also we should also trim the first arg (args[0]) from the --character
if (string.Compare(args[0].Trim('-'), helpInfo.Right.LongName, GetStringComparison(_settings)) == 0)

Can I write code with an expiration date?

I just had this idea for something that I'd love to be able to use:
Let's say I have to fix a bug and I decide to write an ugly code line that fixes the immediate problem - but only because I promise myself that I will soon find the time to perform a proper refactoring.
I want to be able to somehow mark that code line as "Expired in" and add a date - so that if the code is compiled some time after that date there will be a compilation error/warning with a proper message.
Any suggestions? It must be possible to perform - maybe using some complicated #IF or some options in visual studio?
I'm using VS 2005 - mainly for C#.

Mark the code with the System.ObsoleteAttribute attribute, you'll get a compiler warning, which will nag you to fix the code
[Obsolete("You've an ugly hack here")]
public void MyUglyHack()
{
...
}
Alternatively . . .
Write your own attribute, passing it an expiration date on the constructor, in the constructor throw an exception if DateTime.Now >= expirationDate.
The compile will fail until you fix the code (or more likely increase the expiration date, or far more likely you just remove the Attribute.

oooohhh - this is 'orrible. try this for a giggle:
[AttributeUsage(AttributeTargets.All)]
public class BugExpiryAttribute : System.Attribute
{
// don't tell 'anyone' about this hack attribute!!
public BugExpiryAttribute(string bugAuthor, string expiryDate)
{
DateTime convertedDate = DateTime.Parse(expiryDate);
Debug.Assert(DateTime.Now <= convertedDate,
string.Format("{0} promised to remove this by {1}",
bugAuthor, convertedDate.ToString("dd-MMM-yyyy")));
}
}
then, decorate your method/class etc:
[BugExpiryAttribute("Jack Skit", "2011-01-01")]
public static void Main(string[] args)
{
...
}
... nasty :-)
[DISCLAIMER] - created in the name of academic interest, not production code finese!!
[edit] - just to clarify, code compiled and in production will continue to run on/after the 'bugExpriryDate'. only once the code is run in the compiler (on/after the date), will the warning message be raised (debug.assert). just thought it worth making that distinction - cheers MartinStettner.
[caveat] - if used in classes/methods etc would need to be read via reflection. however (and this is interesting) will work straight off in the compiler if used on sub Main(). how strange!! (thanks for the nod Hans...)

I think this is the reason Visual Studio has a Task List. Add the comment:
\\ TODO: Fix this spaghetti by 01APR11
and it will show up like this
.
the keywords are configurable from the options

You could write comment lines in the form
// Expires on 2011/07/01
and add a prebuild step which does a solution-wide replace of these lines by something like
#error Code expired on 2011/07/01
for all lines that contain a date before the current day. For this prebuild step you would need to write a short program (probably using regular expressions and some date comparision logic)
This step could also be performed by a VS macro, which allows for easier access to all files fo the solution but has the disadvantage that it must be installed and run on all VS installations where your project is compiled.

One more option if you have unit tests for your code you can time bomb the tests that verifies your fix. This way you don't introduce strange checks in your production code.
Also I think the best option if you have to put in hack (you've probably already spent enough time looking at it to fix properly... but still want a hack there) than open bug/create task/work item (whatever you use to track future work) and decide if you want to fix it later.

Well it doesn't do exactly what you're asking for but you could use a Debug.Assert() method call which would alert you (in Debug only) that the code has expired. One benefit would be that it wouldn't inadvertently affect your production code (compilation or execution) but would be sufficiently annoying in Debug for you to want to correct it.
// Alert the developer after 01/07/2011
Debug.Assert(Date.Now < new DateTime(2011, 7, 1))

With .NET 6+ this is quite simple when a source generator is used:
Source generator
[Generator]
public class ObsoleteFromDateSourceGenerator : ISourceGenerator
{
public void Execute(GeneratorExecutionContext context)
{
var currentDate = DateTime.Now.Date;
ImmutableArray<AttributeSyntax> attributes = context.Compilation
.SyntaxTrees.SelectMany(s => s.GetRoot().DescendantNodes())
.Where((d) => d.IsKind(SyntaxKind.Attribute))
.OfType<AttributeSyntax>()
.Where(d => d.Name.ToString() == SourceGeneratorConstants.ObsoleteFromDateAttributeName)
.ToImmutableArray();
foreach (var attribute in attributes)
{
try
{
var semanticModel = context.Compilation.GetSemanticModel(attribute.SyntaxTree);
var argumentDate = attribute.ArgumentList?.Arguments.FirstOrDefault()?.Expression;
var argumentMessage = attribute.ArgumentList?.Arguments.Skip(1).FirstOrDefault()?.Expression;
if (argumentDate != null)
{
var date = DateTime.ParseExact(semanticModel.GetConstantValue(argumentDate).ToString(), SourceGeneratorConstants.ObsoleteFromDateAttributeDateFormat, CultureInfo.InvariantCulture);
string? message = null;
if (argumentMessage is not null
&& semanticModel.GetConstantValue(argumentMessage) is Optional<object> tmp
&& tmp.HasValue)
{
message = tmp.Value?.ToString();
}
var diagnostic = Diagnostic.Create(DiagnosticDescriptors.ObsoleteFromDate(message, /*isWarning:*/ currentDate < date), attribute.GetLocation());
context.ReportDiagnostic(diagnostic);
}
else
{
throw new ArgumentNullException(paramName: "date");
}
}
catch (Exception ex)
{
var diagnostic = Diagnostic.Create(DiagnosticDescriptors.ObsoleteFromDateError(ex.Message), attribute.GetLocation());
context.ReportDiagnostic(diagnostic);
}
}
}
public void Initialize(GeneratorInitializationContext context)
{
}
}
Some constants
public static class SourceGeneratorConstants
{
public const string ObsoleteFromDateAttributeName = "ObsoleteFromDate";
public const string ObsoleteFromDateAttributeDateFormat = "yyyy-MM-dd";
}
Build diagnostics
public static class DiagnosticDescriptors
{
public const string Category = "BNX";
public const string ErrorTitle = "Source code error";
public static readonly Func<string?, bool, DiagnosticDescriptor> ObsoleteFromDate = (message, isWarning) => new DiagnosticDescriptor(
id: $"{Category}{SourceGeneratorConstants.ObsoleteFromDateAttributeName}",
title: "Obsolete code",
messageFormat: message ?? "Obsolete code, please review",
category: Category,
defaultSeverity: isWarning ? DiagnosticSeverity.Warning : DiagnosticSeverity.Error,
isEnabledByDefault: true);
public static readonly Func<string?, DiagnosticDescriptor> ObsoleteFromDateError = (message) => new DiagnosticDescriptor(
id: $"{Category}{SourceGeneratorConstants.ObsoleteFromDateAttributeName}",
title: ErrorTitle,
messageFormat: $"Unable to parse {SourceGeneratorConstants.ObsoleteFromDateAttributeName} attribute because of error: {message} Expecting the following syntax: [{SourceGeneratorConstants.ObsoleteFromDateAttributeName}(\"{SourceGeneratorConstants.ObsoleteFromDateAttributeDateFormat}\", \"message\")]",
category: Category,
defaultSeverity: DiagnosticSeverity.Error,
isEnabledByDefault: true);
}
A custom attribute
/// <summary>
/// Triggers a build error at and after a specific system date. Source generators must be included in the project.
/// </summary>
public class ObsoleteFromDateAttribute : Attribute
{
public const string DateFormat = "yyyy-MM-dd";
/// <summary>
/// Build error message.
/// </summary>
public string Message { get; }
/// <summary>
/// System date at and after which the build error should occur.
/// </summary>
public string Date { get; }
/// <summary>
/// Initializes a new instance of the <see cref="ObsoleteFromDateAttribute"/> class.
/// </summary>
/// <param name="date">Required. System date at and after which the build error should occur. Expected format: <see cref="DateFormat"/></param>
/// <param name="message">Optional. Build error message.</param>
public ObsoleteFromDateAttribute(string date, string message): base()
{
Date = date;
Message = message;
}
}
And finally a test:
// The following should result in a build error
[ObsoleteFromDate("2000-01-01", "We are waiting for some Jira thing 1 to complete")]
public class ObsoleteClass1
{
}
// The following should result in a build warning
[ObsoleteFromDate("3000-01-01", "We are waiting for some Jira thing 2 to complete")]
public class ObsoleteClass2
{
}

Without controlling the compiler (possible in the 5.0 timeframe with compiler as a service?), you are not going to have your code expire. You can mark the code as deprecated, or use the Obsolete attribute, or similar, to fire off a warning, but people can ignore warnings (many devs I have met have not learned the rule that warnings are errors).
I think it is a lot of work to try to protect people from themselves. It is even harder when you are protecting them from themselves in the future. Mark the code as a kludge and leave it at that.

Instead of embedding a time bomb, perhaps consider applying a BUGBUG: comment?
Rather than forcing you or someone else to fix code that may be kind of unsightly but works as expected down the road, you can just do a solution-wide search and find the ugly bits when you decide it's time to get down and refactor the really ugly stuff.

Track it in a bug instead. Then it can be properly scheduled and prioritized with other refactoring work.
TODO comments in code can have a tendency to be lost and forgotten. Throwing a compiler error after a particular date will likely lead to that date being pushed forward, or the comment/attribute removed.

I hope i can help with this. take 2 datetimepicker on tool box. And just convert 1 datetimepicker.
private void expired()
{
DateTime expired = DateTime.Parse(Convert.ToDateTime(datetimepicker1.Text).ToString());
DateTime compare = DateTime.Parse(Convert.ToDateTime(datetimepicker2.Text).ToString());
if(expired < compare)
{
MessageBox.Show("This product is expired!");
}
else
}
MessageBox.Show("This product is not expired");
{
}

Both TIME and DATE emit strings and, to my knowledge, there is no way to parse them out at the preprocessing stage.
There are a few methods you can easily do in code to ensure that the code at least warns you at run time. Including an assert is one way, putting in a code comment also works, but the way I handle it is through including a doxygen comment with a note explaining that the function contains a hack, bug, or performance issue that needs to be resolved. This ends up getting filtered by many programmers and is easily viewable on the website for myself or other people to fix.