|
I'm very new to .Net Core so please bear with me!
I'm working on a project that uses EF Core as a data provider. I have managed to set things up so that any outstanding migrations are applied when the applicaton starts by doing the following:
Snippet from program.cs:
builder.Services.AddDbContext<MyDbContext>
(options => options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));
builder.Services.AddTransient<IStartupFilter, MigrationStartupFilter<MyDbContext>>();
MigrationStartUpFilter.cs:
using Microsoft.EntityFrameworkCore;
public class MigrationStartupFilter<TContext> : IStartupFilter where TContext : DbContext
{
public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
{
return app =>
{
using (var scope = app.ApplicationServices.CreateScope())
{
foreach (var context in scope.ServiceProvider.GetServices<TContext>())
{
context.Database.SetCommandTimeout(160);
context.Database.Migrate();
}
}
next(app);
};
}
}
This works fine, using the connection string from appSettings.json.
However - I do not want the SQL account that is used for general data access to have DDL permissions, what I'd like to do is have a different user with the correct privileges that I use just for the migrations.
Is this possible?
|
|
|
|
|
Did you try to create a new/different (not a "DefaultConnection" one) connection string with "different user with the correct privileges" that you need?
|
|
|
|
|
Try setting the connection's ConnectionString property:
context.GetDbConnection().ConnectionString = "...";
context.Database.SetCommandTimeout(160);
context.Database.Migrate();
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
This is precisely what I'd like to do, but I don't want to hard code the connection string in the code, I want to get it from IConfiguration. But I'm unable to inject IConfiguration into my MigrationStartupFilter class because it has to implement IStartupFilter - so I can't add it as a parameter to the constructor for Configure. That's the crux of my issue.
|
|
|
|
|
Just worked it out, I can do
var cfg = scope.ServiceProvider.GetService<IConfiguration>();
to get the configuration service, and from there I can get my connection strings 
|
|
|
|
|
Good morning,
As part of my conduit fill program, I have 8 comboboxes that require the same data filled into each one. They all have the same naming convention, but numerically different.
cbo120VACType_1
cbo120VACType_2
cbo120VACType_3
cbo120VACType_4
cbo120VACType_5
cbo120VACType_6
cbo120VACType_7
cbo120VACType_8
How can I setup the naming to be dynamic in my program, so that it will fill each one, one at a time.
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
The simplest way is to use an array / List of ComboBox items and preload it with the boxes to be filled.
Then a simple foreach will do what you want.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Is this the same data you were previously considering how to store? A lot depends on how much data, how much the data changes, and in how many places you need the data.
Suppose this one form with the eight combo boxes is the only place where you will need this data. You had mentioned building some kind of calculator or estimator, so it could conceivably consist of just one form. If that's the case, you might consider just manually entering the data in the form designer. Each combo box lets you type in the choices in the list.
A step up from that would be to put the values in an array. Then use that array as the data source to a BindingSource. Then use that binding source as the data source to the first combo box. Repeat the process for the other seven combo boxes. You need one array, but you need a binding source for each combo box. This is because a binding source has only one current position, so if you use the same binding source for more than one combo box, setting one combo box will immediately set all the other combo boxes to the same selected item.
Here's a similar question with code.
c# - Populate a combobox with array information - Stack Overflow[^]
|
|
|
|
|
You should say if you're using Windows Forms or WPF or UWP, etc.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Oops, thanks. I didn't pick up on that.
|
|
|
|
|
You may be right. I thought WPF (probably because I looked at another WPF post first. I hate when I do that).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I was just surprised to hear WPF doesn't use Binding Source. I guess I'll find out what it uses when they pry WinForms out of my cold, dead hands.
|
|
|
|
|
The WPF CB's have an ItemSource property which can share a collection and still maintain their own positioning. So it's easier. 
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Is there a preferred way (or is it even possible) to implement some kind of scheme so that only authorized applications are allowed to connect to my service's named pipe instance?
I understand that I can use the PipeSecurity object to control what users are able to connect, but how do I limit it to only authorized applications?
EDIT: I know it's possible, but what is the preferred way of doing it?
The difficult we do right away...
...the impossible takes slightly longer.
modified 26-Jan-22 14:47pm.
|
|
|
|
|
|
Thanks Luc. I think what I'll do is verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Interesting. If that works, it could be a worthy subject for an article...
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
Richard Andrew x64 wrote: verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate
Keep in mind that process hollowing[^] could still be used by malicious code to connect to the named pipe by masquerading as your binary. Verifying the signature doesn't give you very much. You would be back to share permissions and file system ACLs accessible by the caller.
|
|
|
|
|
Randor wrote: Verifying the signature doesn't give you very much.
Thanks for the tip.
Keep in mind I'm not only verifying that the signature is valid, I'm verifying that it was signed with my certificate. Does what you're saying still apply?
EDIT: OK I read the article about process hollowing, and you're right. My technique wouldn't defend against it.
Is there any other method you would recommend to secure the named pipe?
The difficult we do right away...
...the impossible takes slightly longer.
modified 28-Jan-22 14:06pm.
|
|
|
|
|
Richard Andrew x64 wrote: Is there any other method you would recommend to secure the named pipe?
Unfortunately Windows is designed to allow processes to modify the memory of other processes running at the same integrity level. I don't think there is any way to do remote attestation on a named pipe that includes memory integrity.
The only thing I can think of would be running your client under the protection of 'Protected Process Light' (PPL) combined with verification of the code signature. But it's not a good solution, (it's very restricting) and not offered to the general public.
|
|
|
|
|
I wasnt sure how to phrase the question in the subject, but I am writing a program for work that will do fill calculations for conduit.
I need a way to store wire sizes with the corresponding name of the wire, so that its easy to retrieve, edit or update within the program.
I was thinking of using the Settings.settings, but is that the best way/ method to use?
Suggestions?
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
It sort of depends on how many different types there are, and whether you need any other information stored with them. A simple JSON or XML file would work for a reasonable sized sample. Both types are fairly easy to manage in .NET.
|
|
|
|
|
I am storing wire types and their outer dia. size.
2 THHN/THWN & its OD of .378
8 THHN/THWN & its OD of .213
10 THHN/THWN & its OD of .161
and so forth. I would be search for the wire type name to get to the OD for the calculations.
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
I think my suggestions still hold; XML and JSON are common standards so are better than creating your own file format. The only downside is that you need to read all he records into a List<t> before you begin. And unless you have thousands (or even just hundreds) of records then a database is probably overkill.
|
|
|
|
|
If you have it available, an SQL Database is a good approach, because it's easy to share among multiple users and multiple apps - and "basic information" like product / part descriptions have a tendency to grow and get used for other things.
Storing it in a DB means it becomes more readily available company wide, and can thus be used for mreo things.
It really depends on what you are doing, but generally settings is a poor place to keep "general" information - app specific data like where to display it, who logged in last, what colours they prefer, that sort of thing is fine, but once you start with actual data it gets unwieldy.
And while JSON / XML as suggested by Richard are fine, they can get problematic quickly, if they have two or more users / apps processing the same data. Not saying they are bad - I use JSON a fail amount - but I find that they are better for sending "one-time" information rather than as a "updatable" store.
There is also the fun of deciding where to store them: since production software is normally installed in the Program Files folder that can cause problems since it's generally write protected for anti-virus reasons. With a "proper database" the server takes care of that and allows the data to the shared and if necessary updated by multiple sources.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
