Inlining is ages old, but in the old days, there were compilers / debuggers that couldn't handle it properly. If you wanted to step line by line through an inlined function, you had to turn off that feature while debugging. Maybe this applied only to a few compilers. I don't know if the limitation was in the compiler, the debugger or the debug format - it could be either.
There were other optimzing features that you had to turn off while debugging. E.g. an optimizer may detect that you are doing the same calculations twice, arguments being unchanged from the first to the second calculation. So it decides to rather store the first result in a register or temporary variable, and skip the second calculation. Now you set a breakpoint in the middle of second calculation (but not in the first) - but there is no code where the breakpoint can be inserted! It takes some juggling of instructions and breakpoint analysis to handle such situations.
A (true) story from the old days - not directly connected to optimization, but illustrating simlar issues:
This debugger could single step at the function call level (which was more useful than you think - I wish we had it in moder debuggers!), or at the source line level. There was a fatal crash in this 2000 lines(!) function when stepping call by call. When line-level stepping was enabled, the code worked perfectly fine. It took some effort to discover why, and it illustrates the issues when making a debugger:
In line mode, the debugger replaces the first instruction generated by each source line with at BPT instruction, saving the original instruction in its own buffer. When the BPT is reached, the original instruction is re-inserted into the code, the PC decremented to execute the same address again (this time with the original instruction rather than the BPT), the cpu is told to single step at the machine instruction level, and the BPT is re-inserted for the next time this point is reached.
As so often is the case: The culprit was a wild pointer, writing into code memory (the machine did not have separate spaces for code and data), overwriting an instruction. But in line mode, the debugger had a saved copy of the instruction, protected from the wild pointer. So the debugger replaced the destroyed instruction with the correct one; that is why the code didn't crash in line stepping mode.
When it decrypts the first string decrypts fine but the second string gives the error "The input data is not a complete block" if the second string is in quick procession. Example decrypting a column on a datagridview, Searching online the error brings up forums where people say that padding is needed or that Dispose closes to early. However as you can see padding is set to PKCS7 and the call for dispose is as late as it can be. So I really don't understand why it is giving the error.
Setting the padding mode doesn't pad existing data - you need to start by getting the raw encrypted data (before it's translated to Base64 and feeding that into your decryptor.
If that works - and produces an output that is identical to the original input - then do the base 64 conversion each way and check that works. Then compare the Base64 strings against the string passed to your method.
If all of that is right, check the Key and IV byte values against those you used for encryption.
The debugger will give you all that - but we can't do any of that for you - we have no access to any of the information you are passing to the decryptor!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
I have found the problem using debug and it was my own silly mistake.
I was using the code:
for(int i = 0; i < DataGridView1.Rows.Count; i++)
DataGridView1.Rows[i].Cells.Value = Decrypt(DataGridView1.Rows.Cells.Value.ToString());
As you can see each row was getting the value of the first row. So on the first row it was decrypting the string but on the second line it was trying to decrypt the first row that it had already decrypted. Hence the error.
I think I need a break that was quite embarrassing.
Thanks again for your help.
It would be great if you can share the document that is being fed to the ChatBot — the root cause for the "html" is not declared. It is hard to debug it this way, you can read the output of that request and share it here.
And never share the credential on the internet (your SO thread has the credential of your MVP-based profile), and avoid sharing the email address unless you want spam in your inbox.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Although it is difficult to give anything without knowing the context of the usage, but a service principal is what you are looking for if you want to use AD for authentication. Service principal and Azure AD OAuth can be used to automate the login process (check the last link I provided below).