This may be a simple question but I will throw it out anyway.
My company's standard is to encrypt the contents of specific folders on our laptops, so in the case our laptops are stolen, the thieves would have a more difficult time at getting to "sensitive" information.
We are now being asked to encrypt our code that we work on (ASP.NET, winforms, WPF, etc.) for the same reason. Prior to this, our code lives in an unencrypted folder and everything works fine when we try to debug.
I tried to encrypt the folder for one of my projects, built it and started debugging. Note that this is a ASP.NET Web App running on Windows 7. I get the following error:
Server Error in '/' Application.
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to 'c:\dev\rdsims\development\Web\HomePage.aspx'.
Version Information: Microsoft .NET Framework Version:2.0.50727.4952; ASP.NET Version:2.0.50727.4955
Has anyone else encountered this? Do you need more information?
I think I found the answer... By default, it should work. Debugging a vanilla asp.net application on my laptop should be fine because it is running in the context of me, and I have the keys to the kingdom when it comes to encryption/decryption. HOWEVER, the application I am trying to debug runs impersonated as a different user (and thus does not have the proper access). So, the solution is going to be to debug on my laptop not impersonating the user, and then when it migrates out to QA and production, make sure the code is in place to impersonate, etc
Related
I want to publish to IIS the source code of my website (visual studio 2017 web forms website in vb.net or c#) without pre-compiling the project, so I can modify the source code directly on the server with IIS.
I know this is possible, I have done it in the past, and I have seen it done even now, but I cannot figure out what I need to do for this.
When I copy all the website source code to the server with the IIS, the website does not run... any ideas? or where to look for an answer? Is it a matter of setup? of the type of project?
When I call the website I get the following error:
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: The CodeDom provider type
"Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider,
Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be
located.
Source Error:
An application error occurred on the server. The current custom error
settings for this application prevent the details of the application
error from being viewed remotely (for security reasons). It could,
however, be viewed by browsers running on the local server machine.
Thanks!
#Gabe Thanks for the directions:
File - New Project, I see it under Visual Basic/Visual C# - Web - Previous Versions (ASP.NET Web Forms Site)
I tried it, and it works just fine! Basically if you create a project like you describe, you can just copy the source code in a server, without even installing visual studio there, and you can develop the site directly there.
This is ideal when you want to test things directly with external users, test things directly on the live or test servers, and of course you can make sure you have the source code of the project running, without having to keep both the source code and the compiled version.
There are a few drawbacks though:
1) you disrupt the website when you change things, and the application pool is restarted whenever there are changes, users in sessions are kicked out, etc...
2) there is a small delay while the site gets recompiled
3) there are cases where if while the code gets recompiled there are users online, there is asp.net corruption
Thanks for the replies!!
Regards
Manos
I wrote an XML Web Service that run with an unmanaged dll which creates a file for writing.
But when my unmanaged dll tries to use _wfopen to WRITE something into an existing file, it causes a security issue: ACCESS DENIED!! And then _wfopen receives a NULL back.
I originally used _wfopen with r+b to access file. To test the permissions it had,
I tried to change it to use rb (Read file only), then the file opened successfully. This means I can access the file with READ access.
I also found that directly accessing the file through C# code does not cause this problem.
(e.g. if I use File.Create etc.).
The OS I'm running is WinXP Professional SP3 with IIS 5.1. So there should not be directories or files permissions not set properly in such a system.
Is there a way to solve this problem?
After lots of Code Fighting, I came to a conclusion: THIS MAY NOT BE A CODE PERMISSION ISSUE.
So I tried to configure my web service in IIS.
I finally found that configuring the ASP.NET tab of the property page can solve this problem.
On the ASP.NET configuration page, I go to the Application tab and check Impersonate in Identity Settings, and input username/password with my computer login data.
After that, everything went well and the problem was solved.
I hope this helps for those who have the same problem as me.
Thanks for any advice!
Background: I support a classic ASP environment. I have a development setup locally on my machine as part of that support. I am running IIS7.
To access my environment, I use "http://localhost:99999/" (port # faked for privacy purposes). I have not had a problem with this -- until today.
I built an application that is intended to run in this environment. The app is ASP.NET v.4.0 (for sake of example, I'll say it's called "http://localhost:99999/DotNetApp/"). Of course, in order to run this, I had to set up my environment application pool to support it (which it now does).
Problem: after configuring this, I am now getting:
Server Error in '/' Application.
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to '[filepath]\SourceFiles'.
I did NOT get this before I set my IIS configuration. Why am I getting this now?
Note: this ONLY happens with "http://localhost:99999/"; this does NOT happen if I try "http://localhost:99999/default.asp" (the page comes up with no problem).
Anyone have any insight?
Thanks in advance . . .
Edit: Additional symptoms: I tried playing with the application pool settings. The problem goes away if I change the .NET Framework version to either 2.0.50727 or to "No Managed Code." Changing it to 4.0.31319 breaks it. Of course, if I use any of the other two versions, my ASP.NET app won't run.
Edit #2: This problem occurs on ALL links that go to a folder or directory (e.g. "http://localhost:99999/somefolder/"), not just the web root.
Edit #3: I have a workaround: set "http://localhost:99999/" and "http://localhost:99999/DotNetApp/" in separate application pools. The first runs in .NET 2.0, while the latter runs .NET 4.0. (I'll post this as an answer once my 8 hour limit is up.) Probably not the best answer -- I'd prefer something that isn't as much of a kludge -- but for the time being, it'll get the job done. However, if anyone has a solution that enables me to run everything in the same app pool, by all means, post away!
You probably must specify "default.asp" as allowed in your "Default Document" settings in IIS7
EDIT: Check if ASP has been installed: Control Panel -> Programs and features -> Windows Features -> Internet Information Services -> Www services ->Application Development Features-> ASP
EDIT Final solution: The IUSR account is missing from the folder the website is in.
Set the default page for your site in IIS.
Try to set permission "Everyone" for directory "[filepath]\SourceFiles/" or/and "Allow" for other user names and groups in folder properties.
Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.
After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.
If we do nothing but:
1) IISRESET
2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.
And then surf to our web applications, all is fine.
Then several hours later, however, the 500.21 errors return.
What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.
Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?
Text of Error:
Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx
Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers#modules are in system.webServer/modules#name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »
Thanks in advance,
Howard Hoffman
Faced the same problem and the fix was easy.
1) Open visual studio 2010 command prompt.
2) Run the command aspnet_regiis.exe -i
We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.
The problem consistently occurs in this scenario:
1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.
2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.
3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)
4) The application uses HttpServerUtility.Execute during that 1st request.
It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.
Our application is using an 'Integrated' IIS App Pool.
The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.
For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.
So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.
MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.
I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.
The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.
Thanks all for reading,
Howard Hoffman
1. IIS 7 throws an exception as shown in below
2. Open visual studio 2010 command prompt in Administrator mode and execute aspnet_regiis.exe -i
3. Problem fixed, as shown below ASP.Net Application and ASP.Net MCV Application are running smoothly.
The problem more likely is in the application code. The Temporary ASP.NET Files folder contains pre-compiled copies of your app and will be refreshed every time the applications files are accessed. You can pre-compile these files with aspnet_compiler.exe in the \Windows\Microsoft.NET\Framework\v2.0.50727\ folder. Use the -errorstack option allow for more information to be generated about the error you are getting. Long running applications that don't recycle will run into problems if they use a lot of memory or retain large amounts of data in an inproc session state. if your sessions contain large amounts of information, consider using a sqlserver-based session manager.