obviously I don't know your network environment, whether your client is on one subnet and the MS AD/LDAP server on another (routing issues) and what other factors may be involved - MS AD/LDAP running on an under-powered server or all sorts of things in-between
00:00:50:05 (and above)
is hard to swallow - if you have a user looking at a GUI I'd suggest authenticating in the background and keeping the user happy, if its a high speed automated process or something, well, if you cant get a better response time to the server via the network/increase server threads/performance etc I'd be thinking about some 're-architecting' of the software stack, caching ...
My issue is trying to understand where and how platform specific code can be used. i.e. hearing Raspberry PI will support .NET Core I thought "Hey, how I write a UI for that"? But the question might not make much sense. So let's see if I got things right.
.NET Standard: a .NET Standard library target no particular environment and should be supported on all platform that support that Standard library level. These are the new PCL (with a little less hassle).
.NET Core: A multiplatform .NET runtime execution environment. Much like the .NET Framework itself. Except it has less API and more platform support. It can execute latest .NET Standard library as well as .NET Core library.
.NET Framework: A Windows specific .NET runtime and execution environment.
Xamarin Android: An android specific .NET Runtime and execution environment. Can execute Xamarin library as well as .NET Standard library (though some some .NET Standard library calls throw "NotImplementedException" as of now! )
Now if I want to write a PCL UI library that will run on Android I need to delegate some call to some interface / type that will be registered by the Xamarin Android execution environment at startup before it starts the PCL library.
Similarly I am confused as to one do platform specific code in .NET Core. Since I start the .NET Core environment directly (as opposed to a .NET environment specific to the host), how could I stub in native UI technology?
I spent the whole evening yesterday playing with various cross framework compatibility (.NET Standard 1.6, .NET Core, .NET Framework, Xamarin iOS, Xamarin Android, UWP) and I have the feeling the whole thing is... unfinished...
For example, .NET Standart 1.6 is compatible with an, as of yet, unpublished version of the .NET Framework!
Or my .NET Standard 1.6 library was correctly linked into Xamarin Android but had post compile error (creating debug info) with Xamarin iOS, and some method threw NotImplementedException when run on Android.
Anyhow it looks like one will have to wait for .NET Standard 2.0 for better compatibility story, which, last year, they said should be around VS2017 release date....
I will have to wait for 2.0...
Not only tooling and compatibility should be better. But they will have a mechanism in place by then to access the native framework as well... wonder how it will work (they just mention it, but it's not available yet)
Description: An application error occurred on the server. The current custom error settings forthis application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
We can't tell either: you need to read the error message carefully and do what it says.
It tells you exactly what you need to do to get the actual error report to be visible - message, stack, the whole enchilada. Do what it says, and it will tell you which file, which line is caising a problem, and what problem has been detected.
But until you have that, nobody can fix anything.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
For automatic reviews, you can use FxCop and StyleCop. For manual reviews, you really should search the web for manual review processes, read them and agree with your colleagues on the best approach to conduct reviews; that's partly going to depend on your code cycle workflow (do you review pre commit to Source Control, or do you do it post commit and in a separate review stage for instance). We can't really help you that much on that side.
This space for rent
Last Visit: 31-Dec-99 18:00 Last Update: 27-Sep-23 7:44