I've recently inherited a task at my company that involves implementing an application that has currently been running off an employee's windows desktop, and migrating that code to Unix Server used for the office.
The server also runs IBM's websphere, which contains many of the companies larger web applications and uses java 1.6.
Organizational points aside (this is a huge company and much of the coding looks like a spaghetti western, with old legacy systems I wouldn't be suprised if people don't have any idea about), my plans was simply downgrade the code (which was simple as it was from 1.7 to 1.6), then move this application to a runnable jar, and call it via a shell script.
I, however, realize now why this application was never migrated to our production server, as I can't get the thing to run in the UNIX system.
First, I ran into an issue where (and I may be wrong about this) the SSL connections used as part of the application throws an error (same error as this question: Error accessing a Web Service with SSL) After some reading, it seems that any java application run on a server with Websphere (if the application is not in websphere) cannot be done, and thus you have to manually set some java Security Properties to do this (which i did right at the opening of my main method).
After doing that, I get past the initial error, but I am now getting this error
"com.ibm.jsse2.util.j: PKIX path validation failed: java.security.NoSuchProviderException: no such provider: IBMCertPath"
If this has already been asked, I'm sorry, but I couldn't seem to find it. Please link it here and i will close the question.
You are getting the error because something has specified to use the IBMCertPath provider, but java security doesn't know what that provider is.
You need to ensure that com.ibm.security.cert.IBMCertPath is in the provider list in your java.security file. See:
https://www-01.ibm.com/support/knowledgecenter/SSYKE2_6.0.0/com.ibm.java.security.component.60.doc/security-component/gen_info_sec_prov.html
Related
We are developing an (internal) web service based on asp.net 4.8, with a fairly extensive REACT SPA front end.
For debugging purposes during development, we run an IIS server on the local (development) machine, and we do something separate to run a proxy web server for debugging the .js front end SPA (not relevant to the question at hand).
When we start up a Debug session in Visual Studio (2019), VS starts with "Contacting web server to start debugging" and then locks for a time. It clearly does something to start the web server (w3wp.exe), and waits for some reply, before doing what it is told to do in the "Start Action" section of the Web tab on the project properties page.
This is problematic behaviour because it does not attach to w3wp.exe until after it finishes it's "contacting web server to start debugging" operation. This is a huge problem, as our w3wp.exe starts doing all kinds of things that we have no visibility into.
So, can anyone explain to me:
What does VS actually do to "contact the web server"?
Can this be controlled? If so, how?
Can I get the debugger to attach to w3wp.exe right away?
Why does w3wp.exe start up and load its collection of binaries, only unload them and reload them, sometime multiple times?
In short, what the actual heck is going on under the covers at startup?
This (Identity Server 3 Contacting the web server hangs when launching debug mode) question and answer seem irrelevant to my situation
I note the field Override application root URL in the Servers section of the Web tab of the project properties and had hoped this might have something to do with it, but I cannot see any relation.
Partial answers that I will either edit as I find more info, or modify if others correct me, or delete if someone answers completely. The answers to (1) and (2) above are this:
VS obtains the URL of the target web site (I will call this targetServer) from the Project URL entry in the Servers section, Web tab, of the Properties page for the web project. This actually comes from the <webProjectName>.csproj.user file in the project directory. Depending on the selection of the drop down specifying the server type to use, it comes from:
IIS server (<UseIIS>true): the <IISUrl> element
External Host (<UseCustomServer>true): the <CustomServerUrl>
IIS Express: unknown
WARNING: When opening a project with <UseIIS>true, Visual Studio has the very nasty habit of interfering in the setup of your IIS server: it insists on changing the "Physical Location" attribute of the IIS server (that is, the server or virtual app, however you have it set up) to point to the project directory of the web project. Using the "External Host" option avoids this - see https://stackoverflow.com/a/48753054/1082063. (All other discussions of this issue that I have seen incorrectly say this cannot be controlled.)
VS then issues a request to the url <targetServer>/debugAttach.aspx, and the request shows as neither a "GET" nor a "POST", but a "DEBUG", whatever that is. Not sure what VS expects back from this before doing the specified Start Action
Presumably after VS gets some reply from its DEBUG request, it will attach to the process that resulted from this request. Not sure how it knows which process to attach to - perhaps the debugAttach.aspx returns process information?
VS finally executes whatever Start Action is specified in the section of that name on the Web tab of the project Properties.
I strongly suspect that the answer to (3) above is that one cannot get VisualStudio to attach any earlier than it does because it must use the information returned from the debugAttach.aspx request to know which process to attach to. However, putting the line System.Diagnostics.Debugger.Launch(); at the start of Application_Start will allow you to attach the debugger earlier when necessary. (In practice, once you get Application_Start correct, you seldom need to debug it.) See this: https://weblog.west-wind.com/posts/2011/Dec/15/Debugging-ApplicationStart-and-Module-Initialization-with-IIS-and-Visual-Studio for a very good article on the subject.
(4) was a result of quirks in our Visual Studio setup. The initial "hack" used to get around the WARNING in answer (2) just above, was to have a web site with a dummy "virtual path" and have the IISUrl element in Visual Studio point to this virtual path. Then VS could change the Physical path of this virtual path, and we didn't really care, because our Start Action was to start a proxy server for debugging .js in any case. The issue was that this resulted in two calls to Application_start, running on two separate threads: one for the main server and one for the virtual server. Because one of these was happening before the attach happened, we never knew it was happening and it was never caught in a break point. When our application_start became long (timewise - this is not a web server for public consumption...), the two executions of application_start became a nightmare.
The issue you're seeing in IIS is that VS is not launching w3wp.exe, but rather Attaching to Process. In order for VS to attach though the EXE has to be running first, and the time between starting up and attaching (if not already running) ends up being too late to catch the ASP.NET app initialization logic in Application_Start and Module initialization.
As mentioned in my old post there are several ways you can get this to work:
Restarting the application when the debugger is already attached
(by making a change in web.config to trigger an AppDomain reload)
Adding an explicit Debugger.Break() call in Application_Start
Use IIS Express to debug startup code
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
I have an application that runs perfectly fine locally using the VS 2010 application server, however, when I deploy to our web app machine startup just spins and spins and never loads. We have other apps on this same machine that load just fine (this is a debug deployment of same app in product).
I have been spinning my wheels on this for days and I am at a loss as the problem could be.
Here is what I did
Create a new directory (same level as other apps)
Copied over our existing test (www.domain/test/) and it works fine
Build and publish new debug app (www.domain/test/) and it just spins trying to load first form.
I know the diretory is "working" as the 'test' application I put there works fine.
If it's killing the App pool, you might get something in the event log. Fiddler (www.fiddlertool.com) is great http debug tool which let you see if you're in a redirect loop. Also Firefox shows a more meaningful error, something about exceeding the max redirect count.
It does sound like something is looping, but not quick enough to cause a stack overflow, which is odd, because you'd expect it to fail every time.
Simon
Do you have the ability to remote desktop into the machine? If so try running process explorer and look at the process details for the worker process that is giving you issues. Definitely look at the TCP connections being created. If your processor is pegged at 100%, and memory usage is rising then you probably have an endless loop running.
It sounds like it's more related to IIS than ASP.NET. What about the identity that the website is running under? Is it possible that the user the site's running under a bad user, or maybe the password needs to be re-entered?
I did a quick Bing search
There are a lot of postings regarding the error message you described above. Most if not all point to code in your app that is crashing. I know I had a similar problem when I used an automated/threaded daemon utility in my web application. Make sure your code is not bringing down the server, sometimes the VS2010 web server is a little more foregiving than an actual IIS deployment.
If that doesn't work try running a Remote Debugging Session to try and catch any errors being thrown but not handled.
Lastly you could try to setup a new local IIS server to see if you have the same problems. Scott Gu has a nice article about using IIS Express to do this.
I'm trying to do some web development. I cannot start IIS (I need to run some Web Services).
As of about a month ago, the "COM+ System Application" service has started failing with this error:
The COM+ System Application service
failed to start due to the following
error: Access is denied.
DCOM also logs an error in the event log:
DCOM got error "Access is denied. "
attempting to start the service
COMSysApp with arguments "" in order
to run the server:
{ECABAFBC-7F19-11D2-978E-0000F8757E2A}
When I start IIS and the WWW service, everthing seems to work until I hit port 80 on my machine at which time the IIS/WWW services both crash unexpectedly:
The World Wide Web Publishing service
terminated unexpectedly. It has done
this 1 time(s).
The following event is placed in the application log as well:
The run-time environment has detected
an inconsistency in its internal
state. This indicates a potential
instability in the process that could
be caused by the custom components
running in the COM+ application, the
components they make use of, or other
factors. Error in
f:\xpsp3\com\com1x\src\comsvcs\package\cpackage.cpp(1184),
hr = 80070005: InitEventCollector
failed
I have searched google until my fingers are numb. I've searched this site to no avail as well.
I have tried:
running the COM+ System Application service as an administrator.
reinstalling SP3 for XP
giving the "SERVICE" account full control to %SYSTEMROOT%\Registration
removing XP Security hotfixes installed about the time it stopped working
I've removed and reinstalled COM+ (it's possible, check google)
Any insight on the COM+ subsystem, it's files and settings or just how it operates would be greatly appreciated.
I need to get this problem resolved so I can get back to work.
Have you seen this link?
http://support.microsoft.com/kb/909444
I'm having the same problem, and it appears it might have fixed it for me - though I did have to reboot afterwards which isn't explicitly in the kb instructions.
(Though it's hard to tell right now if this actually fixed it, because sometimes for me the problem would disappear on its own after a reboot (which doesn't make a lot of sense given the steps in the kb)).
Sorry all.
I forgot to update this when I found the solution... Well, it was self-inflicted. Some months ago, I removed the execute permissions from dllhost.exe. I hadn't been coding asp.net web apps at the time so I didn't notice the problem and couldn't put two and two together very quickly.
I eventually found it by turning on file system failed auditing on my Windows folder hive. I saw a mess of access denied messages related to dllhost.exe and remembered what I'd done.
Thanks for the help.
I've promised to take a look at an old DotNetNuke installation for a client with the intention of making a few, hopefully minor, changes. The installation is rather old - I believe version 3.0.013 - and the production copy is running against SQL Server 2000, Windows 2003 and .Net 1.1.
As the production server is live and significantly used we need a development installation first. I have attempted to install a copy on my local server - Windows 2003, SQL Server 2005, .Net 2.0, and although with a few tweaks I can successfully get it to display the site, I cannot login, or even access the login module (ie just putting in blank username and password attempting to generate a 'must enter username' type error) without getting the error 'Object reference not set to an instance of an object'
I've spent some time trying to get around this error, without success, although I am hampered by not having used this package before.
So my questions are
Has anyone managed to run DotNetNuke 3.0.x with this configuration (or do I need to setup a box with SQL 2000 and .Net 1.0 to get it to run)?
Any suggestions where I should start looking for this error, or has anyone come across anything similar before?
EDIT: Eventually chickened out and installed in on an old webserver with Win2003/SQL 2000/Net 1.1 and it went in fine on an identical install. So I guess the answer is no, it doesn't work straight out of the box.
My feeling is that you shouldn't have any trouble running in the above mentioned environment. But taking a closer look at the error itself will help us to prove that.
If the error is occurring only when you navigate to the Login module, it may be an issue loading the authentication provider. The best way to find out is to look in the DNN Event Log and take a look at the full error message.
Because you can't login to access the Event Log, you should probably just take a look at the row created in the database when you receive the error. The table is called EventLog and there may be a little bit of friction in parsing the error message out, as all of the details are stored in the database in an XML format.
In general, when moving a site from one environment to another there are only a couple of things that you'd need to do:
make sure you can connect to the database
set the file system permissions
It sounds like you already have database connectivity because you can load the site.
However, you may want to double check (just re-apply) the file system permissions for the root of the website on the machine in question. Make sure the identity of the website (typically ASP.NET Machine Account or Network Service) has 'Modify' permissions on the root website directory. Perhaps the web site can't load a particular assembly due to lack of permissions.