We Keep Coding

All user's sessions reset in browser after updating classes in ASP.net server

Every time I rewrite any class (App_Code folder) and update it on my server, all sessions in the website resets in everybody's browsers.
I have a ASP.net website that I change code in it frequently and when it comes to classes in the App_Code folder, for some reason it decides to reset all the sessions including the user's login. So it happens that after I update the classes (any class) all the users log out automatically and then they have to login all over again. Can you please help me? What am I doing wrong?

If you want Session to survive a restart/reset (which is triggered by your code update), you need to move session to a more permanent storage mechanism.
The most usual suspect is to use a database storage, and most usual'er is Sql Server.
See:
https://support.microsoft.com/en-us/help/317604/how-to-configure-sql-server-to-store-asp-net-session-state
If that link dies, you can just internet-search
<sessionState
mode="SQLServer"
sqlConnectionString=""
cookieless="false"
timeout="20"
/>

Forms Authentication Across Applications has no cookie

I have two applications. The first one is an ASP.NET 4 MVC application that requires authentication. The second is an app that will handle the authentication and set the forms authentication cookie.
On the authorizing app, I call
FormsAuthentication.SetAuthCookie(username, false);
and then I do a simple Response.Redirect back to my MVC application.
In the MVC app, I am making a custom filter that inherits from AuthorizeFilter. On the OnAuthorization method, I was going to decrypt the cookie and grab some additional user data from the authorized user.
My problem is, that
HttpContext.Current.Request.Cookies
has nothing in it. I have checked out fiddler, and the authentication app correctly sets the cookie, and the MVC application gets the cookie, but when it gets to my filter, there is nothing there.
My web.config has in both applications has the exact same setup:
<forms
name=".ASPXFORMSAUTH"
protection="All"
path="/"
timeout="30"
enableCrossAppRedirects="true"
domain="localhost"/>
And I have setup both with the same machineKey to be able to decrypt the cookie. The problem is, I am not seeing any cookie in my OnAuthorization method within my MVC filter.
Right now both applications are running on my local IIS instance.

All the weird behavior was due to the httpRuntime between each application being different. My MVC application was set to 4.5 while my application that was setting the cookie was 4.0. Apparently there was a change in how the crypto happens behind the scenes, and therefore when the cookie came through the pipeline, it would get stripped out as ASP.NET couldn't decrypt it.
I came across this when I manually tried to decrypt the cookie by setting the name property different. That way I could access the cookie and try to dectypt, but at that point I would get an exception.
I found the following link led me in the right direction: Sharing a cookie between two websites on the same domain
By setting the compatibility mode setting on the machine key, the cookie came through just fine and could be decrypted.

Shared login in two MVC Projects? Why?

Imagine when you create a new MVC4 Project and you start registering an account using SimpleMembership and you logged using Remember Me checkbox.
Now, when you create another MVC 4 Project, the application tries to loggin using the previous account, although throws an error because it does not exist. I mean, if a do a login in a web page, the another one uses the same account.
How can avoid this, I guess has to be with ForgeryTokens or something like that

Customize the name of the cookie so that it's unique per application.
<authentication mode="Forms">
<!-- **Defaults** timeout="30" slidingExpiration="true" -->
<forms name=".MyApplication" defaultUrl="~/" loginUrl="~/LogIn" />
</authentication>

if you are using a single sign on mechanism then it is a exceptionable scenario but if you do not wish to allow the same authentication with same account to another website then make sure the web.config file for both projects must have a different machine keys.
Also, this is happened because of cookies on your machine is set to true, to create cookies file and allow access to other project using this cookies details.
< Authentication />

It happens because when the web page is served the browser sees localhost as the domain name. It saves the cookie for localhost.
When you host another website on the same server with localhost, then the browser sends the same cookie again.
If you are using the same cookie name in both the applications, then the system will try to think that the user is already authenticated and you will get the error.
You can change the cookie name in web.config file.
Read this:
Can I change the FormsAuthentication cookie name?

Setting up persistent forms authentication on multiple servers and subdomains

I'm trying to set up forms authentication across multiple servers and subdomains. I have static machine keys set up for each application like so:
<system.web>
<machineKey validationKey="574...7A7"
decryptionKey="2C3...A0D"
validation="HMACSHA256"
decryption="AES" />
</system.web>
...and my forms authentication is configured the same for each application:
<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" />
I've also tried prefixing my domain with a period as I've seen some people suggest, but that didn't work either.
This works fine on my local machine with separate sites set up in IIS for each subdomain. It also works fine on our dev server, where all sites still reside on a single machine. When I deploy to our staging environment, however, the cross-domain authentication stops working. In that environment, I have the primary site (where login occurs) running on a single server, and the secondary site (where my authentication should persist) running on two load-balanced servers. All are running under IIS 7 on either Windows 7 (local) or Server 2008 R2 (dev and staging).
I verified that the machine keys are the same by encoding a string on the primary site with MachineKey.Encode and decoding the result on the secondary server with MachineKey.Decode. I also verified that the .SHAREDAUTH cookie is passed to the second application in the request, both by checking the request headers as reported by Firefox and Chrome, and hooking the debugger to Application_BeginRequest and Application_AuthenticateRequest. I can see the cookie during Application_BeginRequest execution, but it's gone when Application_AuthenticateRequest is called. From what I can gather, that seems to mean that the deserialization of the authentication ticket failed, but I can't figure out why that could be happening in the multi-server environment, but not the single server environment, aside from different machine keys, which I already confirmed was not the case.
I also have a custom MembershipProvider and RoleProvider set up, and those work fine independently on each site.
What am I missing?

So, after a long slog I discovered MS security bulletin MS11-100, which patches an elevation of privilege vulnerability in forms authentication. Unfortunately, the patch is not backwards compatible. It was applied to our load balanced servers, but not to the server hosting the application that created the initial log-in, which meant that the balanced servers couldn't deserialize the authentication ticket written by the app server.
Per the MS deployment guidance article, if you find yourself in this situation, you can add
<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />
to the appSettings section in the web.config for applications on the machines with the patch installed (or to the machine-level config). Or, better yet, make sure you're hosting management company applies the patch to all of your servers at the same time...

For me it works adding this keys in the appsettings:
<add key="aspnet:UseLegacyEncryption" value="true" />
<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />

Use of StateServer with C# Website?

I've got two web portals that are almost identical in architecture. One requires that I add the following to my web.config and enabling the state server, as the logged-in user sessions expire after 2-5 seconds:
<sessionState mode="StateServer"
stateConnectionString="tcpip=localhost:42424"
cookieless="false"
timeout="20"/>
I'd like to know what some of the root-causes are that will cause this issue in one web portal but not the other.
This is a C# ASP.Net v3.5 app sitting on Windows 2008 R2.
Strangely enough, on my local dev box (Windows 7), I don't need to enable this, and the sessions last just fine.
Any discussion on this would be appreciated.

You also need to make sure that you define a machine key, in your servers in the machine.config files, or in your web.config.
I've implemented this scenario successfully on my work servers in a web farm scenario, most recently last week, and it has definitely helped maintain my sessions.
As to why you need to do this ---
The client needs a way to track their session ID. In a farm scenario, depending on traffic, they can be bounced from Server #1 on one page request, to Server #2 on another page request, then back to Server #1 on yet another page request.
This link is pretty helpful.