Lately I've ordered a simple kvm switch. I used to work with two laptops and one desktop display, so KVM is to make switching between the laptops faster and more comfortable.
After getting together switch and all the cables, I found that monitor doesn't work in native mode 1680x1050 on both laptops. However, it was working, until I plugged it with new KVM.
I've tried all available drivers for monitor, even tried to make custom one, as described here
, with no success.
Then I thought, that as needed wide screen mode is not listed in adapter settings, even though the display driver allows it, I have to turn off windows display autodetection feature. No success again.
So, the only solution, worked for me was Powerstrip
utility. I haven't used it for more than 10 years, but unexpectedly, it was the ultimate and only way to go.
1. Open menu from Powerstrip icon in tray.
Choose Display Properties => Configure
2. Change "Standard discrete timing" to "Custom timing".
Go to "Advanced timing options".
3. Go to Custom resolutions form.
4. For my case, there already was needed resolution.
But it is possible to add a custom one as well.
Referring to "ASP.NET MVC" as "MVC" is like calling IE "The Internet"
Just finished up one out of several problems, caused by client's migrating application to the web farm.
This one was about generating token to reset password.
Here is the code responsible for the token generation:
DpapiDataProtectionProvider provider = new DpapiDataProtectionProvider("UpdatePasswordOnce");
userManager.UserTokenProvider = new DataProtectorTokenProvider<CompanyUser, string>(provider.Create("UserToken")) as IUserTokenProvider<CompanyUser, string>;
string token = userManager.GeneratePasswordResetToken(user.Id);
On dev localhost everything worked perfect, but been deployed on the production farm, this code raised an error:
System.Security.Cryptography.CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.
As I understand from short googling session, DPAPI provider cannot work properly with farm/cloud environment. That is why this problem often appears with azure sites.
And there are a few solutions:
Change session tokens implementation, as DPAPI tokens are machine-specific.
Use another tokens provider, utilizing the MachineKey class
However, I went the other way, using solution proposed here:
i had the same issues except i was hosting on amazon ec2. i was able to resolve it by going to the application pool in iis and (under advanced settings after a right click) setting process model - load user profile = true.
So, this time I left implementing own token provider for the azure case, and chose the simplest one.