@AgaveJoe
As it happens, I understand much more about garden design than I do about the internal plumbing of ASP.NET! I'm all too aware of the gaps in my knowledge, which is why I'm posting questions here, in the hope that experts like you can help to plug those gaps :)
Your comment has made me notice for the first time that a fresh new Web Application like the one under discussion does not display a Bin folder in Solution Explorer. An older Web App of mine does have a Bin folder, which looks like it was created specifically to accommodate the needs of ASP.NET Identity.
EDIT: I've found the Bin folder. I'd forgotten that this is hidden unless you click the Show All Files button. Moving my PayPalAPI.cs file to the Bin folder works fine, though not any differently (as far as I can see) from when it was in the root of the project. Thanks for clarifying what PayPal really meant by referring to the "same directory as the SDK".
@AgaveJoe
I only moved PayPalAPI.cs from the root of my project to the Bin folder as that's what your previous post appeared to be recommending. The exact advice from PayPal was "In the directory where you installed the SDK, create a file in your preferred language". That still looks very misleading to my eyes. They made no reference to a dll derived from that code.
In the past, I have often chosen to place such code in a folder of my own creation. In my first forays into the PayPal world I used a folder called MyPayPalCode. However, it works just as well in the root of the project.
You may find that when you reach the age of 77, as I have, you will also find 'interesting ways to go off the rails' :)
PayPal's instructions in Set up PayPal SDK clearly state that the code I have placed in PayPalAPI.cs should be located in the same directory as the SDK. On the assumption that this was an error and they really meant to say in the same ASP.NET project, I have tried moving PayPalAPI.cs into the root of my project.
That now locates PayPalClient in my project namespace and makes it available to PayPalOrder.cs. However, PayPalAPI.cs now generates the error: The name 'JsonReaderWriterFactory' does not exist in the current context. Why is that error occurring when PayPalAPI.cs contains 'using System.Runtime.Serialization.Json;'?
Hi Joe,
Using a fully qualified name of Samples.PayPalClient.client() didn't work. I had already tried changing namespaces but without any success. I can't now remember exactly what changes I tried so I've now given your suggestion a go.
The default namespace for my web app is MyTestCSharpWebApp2, so I changed the namespace in PayPalAPI.cs from Samples to MyTestCSharpWebApp2 and changed the namespace in PayPalOrder.cs from Samples.CaptureIntentExamples to MyTestCSharpWebApp2, but sadly this also didn't fix my problem.
When I switch to the Class View in VS 2019, the class list under MyTestCSharpWebApp2 does not include PayPalClient. It doesn't seem to have access to code located in the Packages folder I quoted.
I apologise for testing your patience. My knowlege of the HTTP request process is very limited, so I was struggling to work out when the next request would occur. Your third attempt to explain this was much clearer to me than your previous attempts.
As it happens, it did occur to me after my last post that checking User.Identity.IsAuthenticated was perhaps both unnecessary and invalid at that place in Login.aspx.vb, so I removed that check late last night. My code was now executed, but failed because I was attempting to identify the UserName by using HttpContext.Current.User.Identity.Name. That had a null value, no doubt for exactly the same reason as User.Identity.IsAuthenticated was false.
This morning, I modified my code to use the name entered in the UserName textbox on Login.aspx and this fixed the problem. I was now able to successfully store a value for LastLoginTime in AspNetUsers.
Thanks for sticking with me despite your frustration with the slowness of my aging brain :)
I am very grateful for your assistance.
I've been using SQL Server since 2009, so I'm well aware of one-to-many relationships. On the other hand, it's possible that I may not be implementing Dr Codd's rules as strictly as he might have preferred.
For example, I have always put more than one phone number column in a single table and that's never caused me any problem. Such numbers are almost always unique to each individual in the communities served by my web sites. However, I have always used a separate Salutations table, as all users share a very small number of salutation options.
What I was asking you to clarify was your earlier comment that "If you do not need a one to many relationship then storing the user information in the AspNetUser table is fine". Are you saying that because I want to make a one-to-many relationship with a Salutations table it would not be suitable to store all my user details in AspNetUsers? If so, what problem would that cause?
My mistake. Salutations does indeed not provide a one-to-many relationship. However, Payments, the other table I mentioned earlier, is such an animal. One user could be associated with multiple payments.
I'm happy to take your advice on this topic, but just out of interest, what exactly would go wrong if I used AspNetUsers for all my user-specific data and linked that to Payments?
I think we must be talking at cross-purposes. The Payments table would obviously have to contain a UserId that links to whatever table is used for my user-related data (i.e. AspNetUsers or a separate Users table).
The thing I'm struggling to understand is your very first response to this thread, where you said "Contact information is commonly stored in a separate table due to standard database normalization. This is especially true if your application stores home and work address or phone numbers; a one-to-many relationship".
Given that I do wish to make a one-to-many link to Payments, my conclusion from the above statement is that there would be some unspecified problem if I stored all my user data in AspNetUsers. That is the problem I am asking you to clarify.
It's a website for a classical music society (https://southamptonrms.org.uk). My plan is to extend it to provide user authentication as a precursor to adding an IPN-based PayPal facility for payment of membership fees. These payments are thus for a service rather than a product, so no shipping address is required. The billing address will come from either the AspNetUsers or Users table. The Payments table will contain PaymentID, UserID, Amount, PaymentDate, etc.
I remain a little confused about your one-to-many relationship comments. Whichever table is used to store my user details will have to have a one-to-many relationship with Salutations and Payments. If that doesn't prevent me from using AspNetUsers then what other form of one-to-many relationship would cause a problem?
Hi Joe,
I have been trying to debug the problem using breakpoints and already know that cookie is generating a successful result before it reaches my newly inserted code.
However, that code is indeed in Login.aspx.vb, which you say won't work. I would appreciate a little more guidance on what would work, as I didn't fully understand your explanation.
Hi LanHuang,
I don't yet have any one-to-many relationship problems. If you read my original post again, you will see that I am a very new user of ASP.NET Identity and was simply asking if the AspNetUsers table was a good place to store all my user-related data.
The first response from AgaveJoe stated "Contact information is commonly stored in a separate table due to standard database normalization. This is especially true if you application stores home and work address or phone numbers; a one-to-many relationship".
I was asking AgaveJoe to clarify that statement.
If you read the comments I posted above on 7 September 2021, you will see that my problem has already been resolved.