Useful VsCode Shortcuts

Toggle Comments             <ctrl>+/

 

Indent Line

Ctrl+]

Outdent Line                    Ctrl+[

 

Sometimes you just need to reboot a Windows desktop over RDP...

 

Sometimes you just need to reboot a Windows desktop over RDP...

Careful, don't select shutdown 😉 

RDP Tips

CTRL+ALT+PAUSE: Switches your Remote Desktop client between full-screen and windowed mode.
CTRL+ALT+BREAK: Force the Remote Desktop into full-screen mode.
CTRL+ALT+MINUS: Takes a screenshot of the active Remote Desktop window.
CTRL+ALT+PLUS: Takes a screenshot of the entire Remote Desktop.
CTRL+ALT+END: Reboots the remote computer.

Press CTRL+ALT+END, then click on the Power icon seen at bottom-right. These are the choices you may see, in Windows 10.I have noticed that with Windows 10 over RDP, typing CTRL+ALT+END will bring up the usual choice of options you get when typing CTRL+ALT+DEL.

By Warren C. LaFrance, Jr.

Dapper+DappersSImpleCrud+Sybase(AseClient).net core errors.

 Dapper+DappersSimpleCrud+Sybase(AseClient)

.net core errors.

Error is something like "Connection in a broken state" , there is an int64 getting passed in, or in the EO/CV/VM, convert them all to int32... inputs first, that's usually the one.

.Net core 3.1 Webapi Errors and Their Causes

 

 

Unable to resolve service for type 'SpProofOfConceptAPI.Dal.IEvaluationFormPartialDAL' while attempting to activate 'SpProofOfConceptAPI.Services.EvalDetailScores.EvalDetailScoresUpdateHandler'."} 

You forgot to declare this type SpProofOfConceptAPI.Dal.IEvaluationFormPartialDAL for IOC in the startup

Solution (and for the BLL cause you usually forget both)

             services.AddScoped<IEvaluationFormPartialDAL, EvaluationFormPartialDAL>();
            services.AddScoped<IEvaluationFormPartialBLL, EvaluationFormPartialBLL>();

A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied.

 When I get this error in .Net Core web api DAL call,  here are things I've found that were the cause.

It's a generic message meaning "something went wrong communicating"

1.     Convert the input args from int64 to int32, because Sybase sucks at int64s. 

2. If you forget to put the @ in front of the argument name in the struct.(Even though on SO they say the @s don't belong)(I tested a working call removing the @ and it worked fine, so this may be spurious)

3. Your timeout could be to short, try adding 'Connection Timeout = 600;' if you are using ASE (Sybase)

4. Try changing all int64s to int32s in the return object

5. Try hard coding the variable into the SQL to see if that works (then you know it's something to do with the parameters.

6. re write not using dapper to see if that gives you insight

 using ( IDbConnection db = new AseConnection( aseSqlConnectionString ) )
                {
                    db.Open( );

                    using ( IDbCommand command = db.CreateCommand( ) )
                    {
                        command.CommandText     = sql;
                        var parameter           = command.CreateParameter();
                        parameter.ParameterName = "@enrtypeid";
                        parameter.Value         = EnrTypeId;

                        command.Parameters.Add(parameter); ;

                        using (var reader = command.ExecuteReader())
                        {
                            // Get the results.
                            while (reader.Read())
                            {
                                var col1= reader.GetString(0);
                                var col2= reader.GetString(1);

                                // Do something with the data...
                            }
                        }
                        db.Close( );
                    }



                }

BUG and work item rules

 

Team, when creating bug work items please refer to these guidelines. Will do another for user stories/developer tasks.  Please let me know if any questions. 

The Description tab:

The description tab should include the following:

• A to-the-point description of the bug the user is encountering.  
  • This description should not include language about what the solution would or should be.  Save that for your comments in the dev notes.  
  • Your target audience of this description includes people with a variety of technical background and different frames of reference.  
  • Make a judgement call on your use of acronyms and developer jargon, please keep things intelligible to the general audience of QA, BAs, other devs, CM, management.  
  • Use complete sentences.
    
    
• A list of steps to reproduce the bug.  If these repro steps are complex, you can save the details for the test case, but it's still helpful to see a general idea of how to get the bug to occur in this section.
  
  
• The expected outcome of performing the repro steps (IE how SHOULD the system behave?)
  
  
• The actual outcome of performing the repro steps (IE the error message or incorrect system behavior)

The Dev Notes Tab:

Each time you set a bug to resolved you should be adding your dev notes with the following:

• Your name and the date you resolved the WI.  
  • In case of multiple comments in dev notes due to a WI being returned, keep your most recent resolutions on top - above the older ones.
    
    
• A description of what you had to change to fix the bug
  
  
• An acknowledgement that you successfully ran through the attached test case on the dev environment (not just your local box). 
  • This step is mostly a reminder to yourself to do the critical step of testing your own changes in our dev environment both inside and outside Citrix.  
  • It will help us catch any configuration issues on the dev server and prevent easily catchable issues that should never even make it to QA.

The Tester Notes Tab:

This tab is used by the QA team to mark their notes on passing a test or describe why a WI is being returned. Dev should not write anything here.

An Attached test case:

All bugs must have an attached test case that amply walks the user through reproducing the bug (should be similar to the steps in the description tab, including more detail when necessary)

Screens affected:

As a developer, it is part of your job to know which screens you are affecting either directly or indirectly with your changes.  It is especially important to make use of this tab to give the QA a heads up on changes that will affect multiple parts of the system, including any reports.  It helps do targeted testing on those parts of the system early, instead of waiting to find an issue lurking during the full regression test, which is done closer to the release date.

How to always run application as administrator , from Warren

 

Got this from Warren, wanted to save it. 

E-

I have sent this out before but I was asked how to do this...

This will actually work for almost any program... 

1. Close all instances of Visual Studio
2. Right click on the Visual Studio icon in your task bar (you will first need add to task bar in windows 10)
3. Right click on Visual Studio and click Properties
4. Click open File Location button
5. Right-click devenv.exe file in that folder appears
6. Select Troubleshoot compatibility
7. Select Troubleshoot program
8. Select The program requires additional permissions
9. Click Test the program and wait for the program to launch
10. Then click Next button
11. Select Yes, save these settings for this program
12. Click Clos