Forgot your password?
Sign in with
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View Python questions
View C++ questions
View Java questions
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Design and Architecture
Internet of Things
C / C++ / MFC
ATL / WTL / STL
Objective-C and Swift
Hardware & Devices
Hosting and Servers
.NET (Core and Framework)
Site Bugs / Suggestions
Spam and Abuse Watch
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Comments by Member 14637786 (Top 11 by date)
The provided MSDN tells nothing to prove your theory?
When HttpClient instance is created using IHttpClientFactory, Dispose(bool disposing) method has _disposeHandler variable set to false, therefore "using" is redundant code which does nothing even if it calls Dispose method. I am not debating here IF it's worse or the same because I believe it simply doesn't matter but if it makes any profitable difference which I am closer to think it does not. I have found several articles that confirms it so far.
No, not really, I believe. HttpClientFactory in Core (or 5, whatever we call it) which is used simply as HttpClient injected through DI is managed by DI container which manages lifetimes of services. HttpClient is a bit of an exception since the practice is to keep it alive and shared between threads as long as possible. Using on var response seems like redundant code to me. Let's wait for other opinions.
Honestly I agree, I am the one who said no to this approach but that's not good enough. I need a decent idea how to make it right. And in my opinion dedicated table per custom type is a better option in terms of clean code, future enhancements and maintenance.
Does it support filtering over the object Value based on real type? Like CustomProperties.Where( x => (double)x.Value == 20.5)?
Post the example of the output you expect. If you want a Dictionary then just deserialize it to it:
var res = JsonConvert.DeserializeObject<list<dictionary<string,object>>>(json);
You do have a dictionary but actually two of them since there are two objects in your collections, you can't just combine them since keys would be duplicated. You need to specify a key like e.g. id and then the value will be e.g an anonymous object with name and type. Depends what you real scenario is.
This is completely beginner/junior kinda code, you didn't even bother to read and understand the problem which crucial part is that it's a self-reference with pretty much unlimited nested levels. Don't answer just to post something. It's littering the page.
Can you show ProductValidator class?
Used to have issues with that and not only me when it comes to maintenance and further development of pretty big solutions so I kinda agree with not using SQL stored procedures for logic. Also problematic when moving to a newer platform and moving the logic with it etc. so again I understand this decision.
But it's not the issue. Also it's pretty easy to pass an SQL command in a form of TSQL string from EF Core to SQL Db and I've thought of that but maybe there's a better way, hence the question.
For now the working solution is getting all the records for a certain path (Include/ThenInclude) and then calculating it in memory just by getting deeper till the condition is met instead doing all the joins on database side. This works just fine as long as the paths won't grow to large ones. That's the only thing I'm afraid of right now but we're far from real life scenarios like that atm.
I'll pass the idea for plain TSQL command send to db but I don't think it'll be accepted.
Also looking forward for any further input from anyone who's encountered this issue.
Unfortunately, we don't store any logic anywhere but API :( Thanks for the suggestion, tho.
My app artifact is just a ZIP now. No docker. Also no ARM template for now, I've just created resources manually through PowerShell. The example scenario I wanna achieve is:
1. I have one Azure DevOps repo
2. I have ARM template for app deployment which will be initial configuration. For now it's like that:
- create resource group
- create storage account
- create plan
- create app service
And ofc the parameters will be different for every instance deployed, different resource group etc.
3. And now I want to deploy my app to the newly created cloud structure based on ARM template.
4. This scenario will be executed multiple times for every newly created app in its own group etc. Basically every client has its own instance
5. Now I want ALL the deployed apps to update to newer version if available on master branch. This may be triggered e.g. manually for now but I don't want to deploy each app one by one because when I deploy like 50 apps, that'd take too much time obviously to just update them to newer version. Would be nice if the existing app on the Cloud could just track if there's a new release on Azure DevOps.
I don't really have much experience with it to choose a proper approach.
Ok, I get it. So the only solution here is to implement setter explicitly and initialize empty collection when null?
Last Updated 1 Jan 1900
All Rights Reserved.