I have had to do some repairs to a legacy classic asp website that uses some VB6 activeX dll's
All of the changes that I have made work completely and have been fully tested on my local machine (windows 8.1), I have deployed to the servers.
drainstop
iisreset
copy files
regsvr32 any new dll's
start after drainstop.
All of the code is working on each of the servers after deployment, but when I use the public side of the site, the changes do not work.
I have looked at the event log and cannot find any problems
This is either permission issue in your Component Services for the objects you've registered, or a setting in your Application pool. Make sure you have Enable 32 bit applications to true and see how often it's recycling. But since you're not seeing anything in the event log about it, it's probably not the recycling.
Related
so after .net core 1.0 got published I started a new console project and imported the code from a small prototype that is supposed to run without IIS. Besides having to use net46 in my project.json due the not-yet updated MongoDB.Driver, that worked fine. When I build the app in Visual Studio a small App.exe with a lot of dll is build and can be run fine locally without IIS.
I then noticed the option to build for IIS Express and thought that I can use the IIS on our server (IIS 6.2, Windows Server 2012 R2) too. It publishes fine with WebDeploy, but nothing happens after that. I was following this official guide. I installed the .NET core Windows Server Hosting bundle and everything appears to be in order, but when I browse to the url, I get a ERR_NAME_NOT_RESOLVED. Theapp.exedoes not appear in the Task Manager and I can't find any log file, although it is enabled in theweb.config. I can execute the app manually, but then it only listens on the defaultlocalhost:5000` address.
If I understood it correctly, the IIS is supposed to act as a reverse-proxy to the dotnet tool which starts a dll, but in my case it's already a compiled exe that works standalone. But I can't figure out how to build a dll from this app..
What am I doing wrong?
If you target full .NET Framework the application will be .exe and not .dll and it is fine. ERR_NAME_NOT_RESOLVED indicates that the url you provided in your browser could not be resolved and the request to the application was not made. AspNet Core Module starts the application on the first request and because the host could not be resolved the request was not made and the application was not started. Once you figure out why the name could not be resolved and you still have issues with making your application work with IIS take a look at my post which explains how things work and how to troubleshoot issues. This, however, only applies after the request can reach your application.
I am a system admin tasked with migrating Classic ASP based web application from Windows Server 2003 (IIS 6) to Windows Server 2008 r2 (IIS 7.5)
The application is very old written in around 2002-03 and the concerned developer people are not around anymore to let me know anything related to this Web Application.
After lot of trial and error, I have been able to get the Web Application running on 2008 r2.
While navigating through application, I am getting various errors which on further investigation I understood are related to DLLs which the Web Application is invoking.
My issue is, I don't know what all DLLs are used/invoked on the source server, which I need to copy & register on the new server.
I tried to use DependancyWalker but I am not able to find a way to use this tool for Web Application.
I would really appreciate this community's help in this regard.
I found out a simple way of finding the DLLs which are specific to my Web Application.
I got a small freeware utility called as RegDLLView from Nirsoft.net which lists all the DLLs which are registered with the Server with File Paths, Description, Company name, etc details.
I found out all the DLLs which my Web Application is invoking by checking the company name and paths of all the DLLs which were listed.
Now I just have to copy these DLLs to my new server and register these on the new system.
It's not rocket science.
When you find a COM component dependancy you can use the ProgId to identify and locate the DLL which is registered in the Windows Registry.
The only DLL dependancies come from COM component DLLs and these can only be invoke in Classic ASP / VBScipt with the
Server.CreateObject("ProgId")
and
CreateObject("ProgId")
respectively.
Wrote about this extensively here
Error ASP 0177: 8007007e Server.CreateObject fails for COM DLL
I have a multi site Azure based web application. One site contains the web pages (with the view functionality driven through jQuery, Raphaël, and HTML) and a thin WCF service. The second site contains a more functional WCF service which in turn calls the data objects that call the database. We stopped development on the site a few years ago but it is still live for the few people who still enjoy using it.
Yesterday I had to fix an cross-site scripting vulnerability someone had reported on the site.
I was alarmed to find that I can no longer run the sites on my local machine under Visual Studio to test and debug any changes before deploying them to Azure.
Because of the interaction between the two WCF sites I had the local debugging set up as follows:
In the Internet Information Services Manager tool (InetMgr) I add additional websites with their physical path set to the location of the source code in the TFS local path on my machine.
I edit the host name in the site's binding to mimic the Azure location, i.e. the main site is projname.cloudapp.net:80 on Azure and projnamelocal.cloudapp.net:80 in my local IIS and the data WCF site is projname-wcf.cloudapp.net:8080 on Azure and projname-wcflocal.cloudapp.net:8080 in my local IIS. (N.B. The main site has a HTTPS binding too.)
I edit C:\Windows\System32\drivers\etc\hosts to include the lines
127.0.0.1 projnamelocal.cloudapp.net
127.0.0.1 projname-wcflocal.cloudapp.net
In Visual Studio I edit the web properties for the main site's project so that it uses the local IIS and project URL http://projname.cloudapp.net/ and I have a switch (in the code to say whether to call the local WCF or the live Azure one.
In the past when the project was under active development this set-up worked fine for locally testing and debugging. Yesterday it failed, one one machine http://projnamelocal.cloudapp.net/ gave a 503 error on another a 404. (N.B. I can ping each URL from the command line so the hosts redirect is working.) Visual Studio complains that it is "unable to start debugging on the web server" and that it "could not start ASP.NET debugging".
I've tried all the suggestions and some:
Running without debugging
Running Visual Studio as administrator (I was already)
Re-registering ASP
Changing the app pool
Giving everyone full permissions to the code directory
Running as my own domain account that is an admin on the local machine
Changing IE to not auto-detect proxies
Adding the sites to IE's list of trusted sites
Turning off IE's protected mode
Restarting Visual Studio
Restarting the PC
Restarting the PC again
How should I set-up this style of running, testing, and debugging local sites work in IIS under Visual Studio?
Got it.
I had forgotten to go to Control Panel > Programs > Turn Windows features on or off > .Net Framework 4.5 Advanced Services > WCF Services > HTTP Activation
Now that I have that installed the local sites start
We have a SharePoint farm configured with one SQL server, an Application server and one Web Front End. All assemblies run from the GAC on the WFE, except one. This one dll has to be forced (using gacutil) into the GAC on the App server in order to see changes in our SharePoint application.
My question is, what determines that this dll must run on the App server and not with the rest on the WFE? I assume because of this, I cannot debug in Visual Studio from the WFE. Do I have to install Visual Studio on the App server as well?
When setting up a timer job, it's possible to use the constructor to specify a specific server. That's likely how things got set up for this solution and associated .dll file. More info on that here:
http://www.martinhatch.com/2009/08/sharepoint-timer-jobs-and-multiple.html
As for adding Visual Studio to servers on your farm, if this is your production farm I do not recommend doing this. If you really need to debug in production (you really, really should have a development box set up for this), do it via remote debugging.
I'm running Visual Studio 2010 and IIS 7.5
My site accesses a specified servers hardware for some statistical analysis.
When I debug my site in Visual Studio, I can access other servers hardware information with now issue. When I publish the site to IIS running as ASP.Net 4.0 appPool because the site is written under the 4.0 framework, the hardware retrieval fails. (note: when I run the site and analyze the local machine hardware, it works perfectly... the problem lies in analyzing another machine on the network.)
My question is, What is the difference in permissions a site is running under when debugging in Visual Studio in comparison to a published site in IIS 7.5?
Things I've tried...
Changing the app pool identity to every possible built in option, and my own domain profile, which is local admin on the machine I'm trying to retrieve hardware info about.
Changing the user that access the file directory of the website.
Changing app pools period. (The site has to run under .net 4.0, or else it barks out bad things).
I'm thinking I may need to install the site directly on the server that's being analyzed, but I find it odd that I can get all the data from other machine when I'm debugging. Any insight someone could bring would be greatly appreciated. Thanks!!
This answer is, in some cases, you have to add the appPool identity running the site to the "Performance Monitoring" group for the local machine in order to allow an ASP.NET site access the server's local hardware resources...