I have inherited responsibility of setting up IIS after a server migration. I have never used IIS before, however, I am the only one in my shop that has the programming ability to modify our intranet site(which is rare and wrote 10+ years ago by someone no longer here), which is hosted on the IIS. I have limited exposure to .NET.
We were at IIS 6.0 and migrated to IIS 8.5.
The intranet site is written in VBScript. There is a .asp script that uses a DLL. The DLL is 32 bit.
Here is a sample of the script and call:
<%response.write(DataTypeConversion.ConvertDate(x.value,"1","0"))%>
The DLL is named DataTypeConversion.dll Within the DLL is a function ConvertDate().
Currently, when this piece of code executes, the script errors out and stops running. I have tried to register the DLL with REGSVR32.
I have read where this may be an issue of IIS now being 64 bit trying to use a 32 bit DLL. However, I have had no luck on that front either.
So, if I were to write a custom DLL, how can I make that DLL callable in a script like in the code example above?
Thanks
In .NET, you could make a "Class Library" project. Then, under "Project", "Properties", Application, "Assembly Information...", check the box to "Make assembly COM-Visible". You might also want to read about "Strong Names".
This SO article has some pretty thorough instructions: How to access .Net dll in classic asp?
Related
I am having a problem setting up a website hosted on Windows Server 2012. The website is just the default website you get when setting up a new "ASP.NET Web Site (Razor v2)" site. Then I simply published it using the "Publish Web Site" option in VS2012. I have also added the .cshtml extension in the MIME types. The server is running IIS v8 and .NET v4. The problem is when I visit the website this is how it displays:
http://i806.photobucket.com/albums/yy341/SamuelCB/Razor%20Error/Untitled.png
Is there anything I am missing?
Items to check:
rarely do MIME Types actually matter if IIS and ASP.Net are installed properly
don't mis-interpret this statement, I'm not saying MIME types don't matter, just that if/when configured properly all of this, IIS/ASP.Net is "out of the box" without mucking with MIME types.
The issue with adding ".cshtml" manually is that IIS will (now) serve it, but the ASP.Net engine isn't (necessarily "there" for) handling it (e.g. integrated mode). That's why you're seeing the "unparsed" (raw) version of the file...code and all...it's all IIS (no ASP.net engine is configured to handle it).
if you run your own box, run Web Platform Installer - and it should give you insight on what's installed vs. what's not. Pay attention to ASP.Net bits and versions. You may need to (re)register ASP.Net
if you're hosted, just because your host has .Net Framework 4.x installed, doesn't mean they have all the bits and pieces of ASP.Net installed as well. Ask your host for guidance instead of doing a guessing game. I often have to "load" things that my dev machine has "by default" (of course its my machine) because I end up with non-functioning stuff when deployed to my host. You're not even getting an ASP.Net engine error, so that's a sure sign ASP.Net needs some work.
Nuget is excellent for this task. Some items that might be necessary to be "bin deployed" (aka. you have to add them to your deployment/upload to /bin directory on your host):
Microsoft ASP.NET Razor
Microsoft ASP.NET Web Pages
Microsoft.Web.Infrastructure
Unrelated: This sounds more like it should go to ServerFault rather than here on SO...I don't mind...but the community may think differently...and you might even get better answers....
Hth...
Hi guys,
We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.
I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.
To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.
What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?
[edited question]
Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.
To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.
You should seriously look at web deployment projects for visual studio 2008.
This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.
In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.
The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.
Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.
Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.
You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.
Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.
If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.
Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.
It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.
I'm trying to run a test version of a web using the File System (i.e. the "Cassini" web server built-in to Visual Studio 2005) rather than (IIS 5.1 on my Win XP dev PC). This web is a hodge-podge of classic ASP files written years ago and some new development in ASP.NET (VB.NET).
How can I get past this error message as it tries to go to /TestWeb/default.asp? -
Server Error in '/TestWeb' Application.
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.asp' may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /TestWeb/default.asp
Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082
Things I have checked and previously encountered trying to get this mess working:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
(has nothing for *.asp nor
HttpForbiddenHandler so nothing to
comment out).
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
(has nothing for *.asp)
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config
(had a HTTPForbiddenHandler for
*.asp but I commented it out as per other postings advice; seemed to
have no effect for me though).
To get past an earlier error
("Request for the permission of type
'System.Web.AspNetHostingPermission'
failed"), I had to go to
"Administrative Tools > MS .Net
Framework 2.0 Configuration > My
Computer> Runtime Security Policy >
change Local Intranet to Full Trust.
To get past an earlier error ("the
network bios command limit has been
reached") I had to "enable a hot
fix" by adding the following DWORD
value at the following registry key:
HKLM\Software\Microsoft\ASP.NET\FCNMode
and set the value to 1 (per MS KB
Article 911272).
This whole web has been placed on a file server in our LAN and from my desktop VStudio2005 views it via the mapped drive letter (e.g. V:\SVNwork\myFolder\TestWeb)
Visual Studio 2005 models this as a "web site" (not a "web application project").
The remainder of this post describes some background about why I am trying this:
We tend to recreate the web site on our dev PC's which run IIS 5.1 on Win XP. Movement of new stuff into production can be awkward using WinDiff and copying files as needed.
I'm trying to implement source control over this work. I've had a heck of a time trying to configure Visual SourceSafe 2005 and local IIS to work together smoothly (interestingly, I had pretty good luck putting "web application projects" under VSS2005 so I think it's related to the awkwardness of the ASP.NET 2.0 "site" model and VSS).
Anyway, I've moved a development version of this classic ASP and ASP.NET to a common file server in our LAN. Before placing this under Subversion control as a working copy of it's equivalent imported into a repository, I just want to make sure it can work with the Cassini web server. That's where I am stuck. The ultimate goal is have this under SVN and view differences with TortoiseSVN.
Thanks for reading this far...hopefully someone can get me past this error and then I can move forward with the SVN and TortoiseSVN work.
Cassini doesn't, as far as I can tell, support classic ASP. An alternative would be to run a local install of Apache (since you can't/won't use IIS) which will host ASP, but is probably asking for trouble.
See also: http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx
You could also run local IIS, which will, of course, host both ASP.NET and classic ASP. Visual Studio can easily be configured to debug with a local IIS install.
Points for moving to subversion: we use the Microsoft stack (Visual Studio, ASP.NET, SQL Server) with subversion and it works very well.
Subversion comment
GRRR.. bosses are fun. The svn model is known as copy/modify/merge. The repository lives in a central location - probably your file server. Using the svn client - or a Visual Studio plugin like the excellent AnkhSVN - each developer gets a LOCAL working copy,makes their changes and performs a "commit" when they're done working on a file.
SVN takes care of making sure that developers don't overwrite each others changes, provides a facility for merging changes when someone has modified a file between when you got your last copy and when you commit your changes, etc.
The whole point of a working copy is that it isolates developers from each other. The merge/commit step takes care of intergrating everyones changes. Having a central working copy that everyone works from defeats the purpose.
This is a very different approach than that used by Visual SourceSafe, which is basically a file locking mechanism. The fact that SVN is a real client-server application (where VSS is simply a disk-based "database" with no server app to administer it) provides all sorts of capabilities. We check out, modify, commit, then publish from svn to a dev server.
Also, if I remember correctly, Cassini won't server apps from a mapped drive.
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.
Its been a long time since I had to do anything but minor fixes with ASP.NET and I've never deployed a ASP.NET 2.0/3.5 application so probably I'm just missing something simple but I definitely need help.
Basically, we have a poorly written .NET 1.1 web application and we had some contractors come in and break some of our third-party dependencies and update it to a poorly written .NET 3.5 web application (the poorly written part will be addressed later).
So now I'm practicing deployment scenarios on a virtual machine set up like our deployment environment.
I installed the 3.5 framework
I compiled the new code and used visual studio's Build>Publish option as recommended by the contractors to output only the files the application requires.
I copied all the files to a new directory inside of Inetpub on the VM and configured the web.config
I created a new application pool
I created a new IIS website pointed to the new directory and using the new application pool. I configured it to use version 2.0 under the IIS ASP.NET tab
But navigating to the loginpage I get:
Parser Error Message: The file '/View/LoginPage.aspx.cs' does not exist.
Line 1: <%# Page Language="C#" MasterPageFile="~/MasterPage/LoginMasperPage.Master" AutoEventWireup="true"
Line 2: CodeFile="LoginPage.aspx.cs" Inherits="MyApp.View.LoginPage" Title="MyApp - Login Page" %>
What gives? In the .NET 1.1 version of the application all the c# code was compiled into the MyApp.dll and the application knew to look there. Double checking with reflector, all the code is in the binary here too, just the server isn't looking there for it.
What can be going on? I can wait for the contractors to get in tomorrow, or compile everything including the aspx files into the binary, but we have good reasons for keeping the aspx files uncompiled and I'd like to deploy today if possible.
Please note, that this is not ASP.NET MVC, the view namespace/directory is simply where all the webforms are kept
You have probably used the Web site model for your updated application. Consider using a Web application project instead.
Change the CodeFile= reference to CodeBehind= in the "<%# Page" directive.
In visual studio try this. Click on your web application project. Go to Build > PUblish > Choose the location > click publish. That will build everything and put all the .cs files into a single dll file. It will also leave your html/aspx files in their same locations. This allows you to do what you need to do with the aspx code, while keeping all your cs hidden away.