|
When you refer to Role, what exactly is that? Is a Role in the sense you're referring to something that can be defined by the System Admin?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Role is your concept, AD works with GROUPS and a user is a member of 1 or more groups, a heavy security requirement can be a nightmare. We had to get creative around the name of the groups to support department and role. Typically
Finance_Op = finance operations
Finance_RO = read only.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
The article you describe as "old" has #337 votes. There's a comment with code suggestions in Oct, 2016, which the author acknowledged.
Is it too much to ask that you review more than one article on CP (out of many) ? [^]. Or that you visit StackOverFlow, and sample possibly relevant sources.
"If not you, who ? If not now, when ?" (sometimes attributed to Hillel the Elder)
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
BillWoodruff wrote: Is it too much to ask in this instance, probably.
|
|
|
|
|
I pointed out that it's old because AD has evolved over time. Some of the comments pointed out that there are newer ways of doing some of the things the article discussed.
BillWoodruff wrote: Is it too much to ask that you review more than one article on CP (out of many) ? [^]. Or that you visit StackOverFlow, and sample possibly relevant sources.
That's an assumption on your part that I haven't looked at other resources.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Having a AAA source like LDAP is how things should be done for any non-trival application with securables. It does a few things for you, such as de-obligating the engineer from concerns like identity and role tracking, and makes things grotesquely easier from an operations standpoint. If someone leaves the company, just disable 1 account rather than having to check each application and remove accounts.
While I respect Richard's advocacy of System.DirectoryServices.AccountManagement (S.DS.AM), I've played with the namespace some and, depending on the use case, have found it to be restrictive and slow. There are three namespaces for using AD in three different ways, and each has strengths and weaknesses. S.DS.AM is the newest library, and it has a number of helper functions out of the box and is streamlined a bit, but it interfaces with the MS ADSI interface, which is an entire operational layer that exists at a higher level than LDAP. The base namespace, System.DirectoryServices (S.DS) is less streamlined, but more flexible, but also leverages the ADSI interface.
I generally use System.DirectoryServices.Protocols (S.DS.P) since it doesn't touch ADSI and goes straight through as LDAP. The library is minimalist, so learning to use it can be tricky, but it is several orders of magnitude faster than the alternatives (and I mean hundreds), so if you find yourself working with multiple records it can be a life saver. It also de-couples you from Active Directory by targeting LDAP directly, which can be implemented in a few different ways.
Here's pretty comprehensive intro to S.DS.P if you're interested.:
Introduction to System.DirectoryServices.Protocols (S.DS.P)
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
..
modified 19-Nov-17 11:55am.
|
|
|
|
|
What "session code"?
What is it supposed to do?
When is it supposed to do it?
Remember: we know nothing about your project, and I for one am not going to wade through your whole project trying to to work what you haven't done!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hi all,
I have a question.
I have to insert oracle table values in Access database.
I am storing oracle table values in datatable(dt).
In oracle and Access database "Net" field is a "Number"
Trying to insert "Net" field in access datatype i am getting following exception.
"Data type mismatch in criteria expression."
I have found out the reason is "Net" field value in oracle table is EMPTY ("").
What i did is trying to check the field IsNullOrEmpty, if it is Empty then i want to store null value into "Net" field(In Access database).
I have made some code change after that also receiving the same error message .
""Data type mismatch in criteria expression."
Please help me how to fix this.
What I have tried:
strNet = !string.IsNullOrEmpty(dr["NET"].ToString()) ? dr["NET"].ToString() : null;
if (dt.Rows.Count > 0)
{
foreach (DataRow dr in dt.Rows)
{
sInsertValues= "'" + strNet + "'";
insertAEdetails.ParmValue = sInsertValues;
insertAEdetails.InsertIntoAccess();
iNbrInserts++;
}
}
|
|
|
|
|
Yuck. Create an Oracle "extract", fix that, and then import into Access.
Or use Access directly to access Oracle (link or import).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
sai.2012 wrote: sInsertValues= "'" + strNet + "'"; That turns everything into a string, and a string is not a number. Next, you'd want DBNull.Value, and not "null". Lastly, if a number-field in Oracle is empty, it is a DBNull, and not an empty string.
Fetch it as a number (Int32), save it as a number, and use command-parameters. That would also eliminate the redundant .ToStrings-calls.
Something like below;
Int32 someValue = Convert.ToInt32(dr["NET"]);
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
We have developed a .NET DLL using Visual studio 2015 targeted to .NET framework 4.0 .
We need to implement the licensing functionality for Design time and runtime .
Could you please suggest the best way to do that.
Note: This is just a .NET DLL NOT a component
|
|
|
|
|
|
I am new to using the "async" functionality in .NET. I have created a few GUI classes that are designed to give feedback to a user while time consuming tasks are completed. The core of this functionality is a "Task" class that makes use of the System.Threading.Tasks.Task class. It contains the "description" of the task being completed, the number of steps to be completed in the task, and the System.Threading.Tasks.Task task that is to be called within an async method. This "API task" that is the actual "task" to be performed amounts to calling a function within the class. The problem is that the creation of my "Task" action is causing a TargetInvocationException. I am getting the impression from the inner exception that the System.Threading.Task.Task is effectively a "null" task and I do not have the experience to understand why. Here is my code inside the async method:
async void OnGenerateMapData()
{
statusPanel = new StatusPanel();
statusPanel.AddTask(new Task("Processing Map Data", 1081 * 1081, true, new System.Threading.Tasks.Task(() => { ProcessPixelData(); })));
statusPanel.AddTask(new Task("Generating Shoreline", 1079 * 1079 + 50000, true, new System.Threading.Tasks.Task(() => { ProcessShoreline(); })));
statusPanel.AddTask(new Task("Updating Map", 1081 * 1081, true, new System.Threading.Tasks.Task(() => { UpdateResult(); })));
statusPanel.Dock = DockStyle.Fill;
this.Controls.Add(statusPanel);
Task currentTask = statusPanel.BeginTasks();
while (currentTask != null)
{
await currentTask.Action;
currentTask = statusPanel.AdvanceCurrentTask(0);
}
this.Controls.Remove(statusPanel);
statusPanel = null;
}
It may help to know that all the function calls being put into the "task" are within the same class as the async method. However, perhaps I need more information (such as a this. before the call)? Or is doing this illegal in its entirety?
EDIT: Just in case it helps... here is my Task class:
public class Task
{
bool displayAsPercent;
int currentItem;
int totalItems;
object result;
public System.Threading.Tasks.Task Action { get; private set; }
public string Description { get; private set; }
public bool IsComplete { get { return currentItem >= ItemCount; } }
public int TotalItems { get { return totalItems; } }
public object Result { get { return result; } }
public object Baggage { get; private set; }
public bool Started { get { return currentItem > 0; } }
public int ItemCount
{
get
{
if (displayAsPercent)
return 100;
else
return totalItems;
}
}
public int CompletedValue
{
get
{
if (displayAsPercent)
return (int)((float)((float)currentItem / (float)ItemCount) * 100.0f + 0.5f);
else
return currentItem;
}
}
public Task(string description, int stepCount, bool displayAsPercent, System.Threading.Tasks.Task task)
{
currentItem = 0;
Description = description;
totalItems = stepCount;
this.displayAsPercent = displayAsPercent;
Action = task;
}
public void Begin(Task previous) { if (previous != null) Baggage = previous.Result; ++currentItem; }
public void Advance() { ++currentItem; }
public void Advance(int increase) { currentItem += increase; }
public void Complete() { currentItem = totalItems; }
public void Finalize(object result) { this.result = result; }
}
modified 15-Nov-17 13:35pm.
|
|
|
|
|
A TargetInvocationException[^] always has an InnerException which will give you a better hint at what went wrong - take a look at that in the exception explorer (or however that's called) which you can open from the exception dialog that Visual Studio shows you when it occurs.
If I had to guess I'd say it's probably an invalid cross thread operation on your controls: Controls can only be accessed by the UI thread. See How to: Make Thread-Safe Calls to Windows Forms Controls | Microsoft Docs[^]
On a different note: Usually, when developing applications with a UI, the goal is to separate UI logic from business logic in order to end up with an easily maintainable architecture. That's the point of those patterns like MVC, MVP, MVVM. Your approach looks like the exact opposite (placing the tasks into your custom control classes).
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Thanks for the feedback. Honestly I tried this approach because as I was typing code, while trying to figure out how to make the UI work the way I wanted it to, I ran across the await keyword which I was not familiar with. My goal is to disable the main interface and pop up a progress bar that keeps itself updated while the program waits for the "tasks" to finish.
I don't necessarily need to use asynchronous processes if I can find another way to achieve my goal. I wanted to change my original design by creating a "modal" progress control (not a dialog, simply a feedback control that disables all other application controls and greys them out). I could not find a way to do that so this was my solution. What I really want is to keep this organization (because contrary to the "normal" logic, this approach is easy to maintain in context of this program) and make it so that the UI updates properly. The design I was using before never updated the progress bar (which was on a status bar at the bottom), making it look like the program was not responding. The UI doesn't like to update at all during CPU intensive processes. I figured separating the processes might help overcome that.
EDIT: One other note. As I hinted in my OP, the inner exception refers to a null object reference. I am assuming that this is due to the fact that the statusPanel is being created asynchronously or somehow the Task being created is resulting in a null object.
modified 15-Nov-17 16:03pm.
|
|
|
|
|
I think you misunderstood - I didn't want to imply that you shouldn't use tasks (or worker threads in general). For keeping the UI responsive/updating a progress bar while a lengthy operation is in progress it's the only option you have. Just when you do use tasks/threads you have to make sure you don't directly call control's methods but invoke that on the UI thread (which is likely the cause of the TargetInvocationException) - take a look the the link in my previous reply.
And I would recommend to separate the tasks from your custom control classes, but that's a design issue and not the immediate cause of your problem here.
Can you show the stack trace of the exception and the code where it occurs?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
If I was starting out on "multi-threading", I would get familiar with the BackgroundWorker (BGW) and DispatcherTimer classes first; they are more intuitive than "Tasks" (IMO).
(BGW can update the UI in the ReportProgess callback; while DispatcherTimer runs on the UI thread, so even simpler).
I created generic "adapters" of the above classes that will accept an object with a interface for "DoWork", "ReportProgress" and "Completed"; and "run with it".
Once you have your "pattern" down, adding new "threads" is trivial.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
As I said/implied in my reply to Sacha, the implementation isn't as important as making sure that the user has been made aware that the program hasn't stopped responding by giving feedback. That is one of the really annoying things about .NET. In my experience, the UI doesn't update when it is supposed to while a CPU intensive process is running on the UI thread; even if that process consistently performs changes to the UI. So as long as the UI updates properly, and the code is logically organized (and easy to maintain), I don't care which convention is used.
As far as "tasks", I simply mean calling the method that performs a specific "step" in the process being reported to the user. My Task class combines these together into one, easy to maintain, logical entity.
I will look into your suggestions.
|
|
|
|
|
The point was, BGW and DispatcherTimer were designed with "UI updating" in mind.
Obviously I wasn't clear enough on that point; but, "task" away.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Thanks. This tip really panned out. I was even able to use the DoWorkEventHandler delegate as a parameter to set up the handler callback as part of of my custom Task class. Very convenient.
|
|
|
|
|
Yes .. you got it!
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I am getting another problem. As far as I understand it, the background worker "finishes" when the DoWork callback has completed. I have a method that is called when the UI detects that the task is completed which is supposed to make sure the background worker doesn't get messed with when it is done. It is supposed to prevent cross-thread issues (the RunWorkerCompleted handler sets BackgroundWorker to null to try and prevent the exception below) while still making sure that the UI is updated and the worker "knows" it is supposed to be done. That method is below:
public void End()
{
if (BackgroundWorker != null)
{
if (BackgroundWorker.IsBusy)
BackgroundWorker.ReportProgress(100);
BackgroundWorker = null;
}
}
However, the line with the call to ReportProgress crashes with this inner exception:
"This operation had OperationCompleted called on it and further calls are illegal"
First, if the operation has been completed, how come the handler for RunWorkerCompleted hasn't been called yet (I put a break in the handler's first line so I know this for certain)? Second, if the operation is completed, how can it be "busy"?
|
|
|
|
|