Situation:
We created an assembly with our own ASP.NET control.
That control registers some resources (images, JavaScript files, etc);
There is a web-application which uses our control.
The control is loaded well and get access to internal resources. In result HTML code all calls to resources look like "/WebResource.axd?d=...".
So far, so good.
We have two computers: first - Win7 32 used for development, second Win7 64 - for testing.
The problem:
The assembly generated on Dev machine works well on it but give 404 error for all requests to WebResource.axd when running on Testing computer.
If we just copy the sources to Testing computer and build our assembly there - it works well on both computers.
We use .NET 4.0. All latest updates are installed on both computers. Web application which uses our control runs right from VS 2010 (under ASP.NET Development Server).
Any suggestion?
We've found the problem.
Our testing computer had wrong date/time set (10 days before the real date). So our assembly (built on development system) was considered by it as a "DLL from the future".
And it seems ASP.NET can stand the assembly "from future" but it does not like "future" resources placed into that assembly.
Once we corrected date setting on the testing system - everything started to work well.
Hope this case will help somebody else.
The assembly with your asp.net control may not be included in your web application deployment.
Look for the reference to your assembly in the web application, right click it and select properties.
Look for the copy local box, and set it to true.
recompile the application and redeploy it to the other machine.
Related
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
Recently we moved classic asp application+ vb6 com components from W2K3 server to W2K8 server.
The only change made in the vb6 component is upgrade from MSXML 2.0 to MSXML 6.0. These vb6 components are compiled into dlls and registered as COM components on the server.
The issue we are facing right now is that asp pages are taking a lot of time to load.
The functionality which used to take 8-10 sec is now taking around 40 seconds.
We inserted the logs and found that all the functions in vb6 code which are related to MSXML 6.0 upgrade have caused the slowness in the application.
On further research, we found that vb6 modules which uses 64 bit version of MSXML6.0(present under C:\Windows\System32) to load XML documents takes over two times longer to load an xml doc which uses 32bit version of MSXML6.0. (present under C:\Windows\sysWOW64)
Microsoft has provided a hotfix for this. Please see below url.
http://support.microsoft.com/kb/2799406
We already tried this hotfix but it did not fixed the performance issue.
Question:
1) On W2K8 machine, we are unable to use MSXML6.0 present under C:\Windows\sysWOW64. Whenever we try to reference to this location it by default references back to C:\Windows\system32. We also opened the vb project file in a notepad and changed the reference location and opened the Project again but no success. Can anyone suggest what can be the probable solution to fix this?
Current Scenario:
Reference=*\G{F5078F18-C551-11D3-89B9-0000F81FE221}#6.0#0#..\WINDOWS\System32\msxml6.dll#Microsoft XML, v6.0
Expected Scenario:
Reference=*\G{F5078F18-C551-11D3-89B9-0000F81FE221}#6.0#0#..\WINDOWS\sysWOW64\msxml6.dll#Microsoft XML, v6.0
2) Once we compile this vb6 code to a dll by having a reference to this sysWOW64 folder, how to ensure/confirm reference from Syswow64 will be picked up once it will be on W2K8 server?
3) Also if you can suggest what can be other areas we should target/think of for resolving this performance issue?
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've been trying to migrate a fairly large web application from IIS6 to IIS7 the past few days, but every time it seems like we're about done, IIS7 fails to load aspx pages.
The application is a .net 3.5 webapp that makes heavy use of reflection and web services. We use 2 main components (each with their own web site in IIS7 although they share an application pool): the web UI (aspx pages), and the webAPI (asmx pages).
The webAPI portion runs perfectly (as far as we can tell; there are a few things we can't test from the browser), and the web UI pages load static HTM pages just fine. The problem is that once we attempt to view an aspx page (any aspx page), the whole thing just comes to a halt; no error is logged in the event viewer until a few minutes later when we get an IIS 5010 warning (worker process ignoring ping).
We've attempted to migrate the app in two different ways:
Manually: we moved all the necessary files and set up the virtual directories then converted them to Web Sites. Result: the worker process took up 100% of a single core and spun forever (until terminated manually)
Automatically: Utilizing the MSDeploy application from www.iis.net we archived the entire IIS6 web server and unpacked it into a blank IIS7 install. We had to turn off Forms Auth to get rid of a 401.2 error, but after that the result here was that the webAPI component still works just fine, but instead of the web UI worker process taking up 100% of a single core, it grew to about a third of the required memory then hung out doing nothing.
Either way, what happened from the user's point of view was the same.
Unfortunately, we can't even attach a debugger to the worker process because it doesn't seem to be loading managed code.
Details:
.net framework: v3.5
CLR version: v2.0
IIS Authorization mode: Anonymous
OS arch: x64
App arch: x86
Happens with both classic and integrated pipelines
Notes:
New web projects seem to work just fine in IIS7 and, of course, xml web services are also fine
temporary DLLs are created and stored in the temporary ASP.net DLLs folder, even though the worker process never seems to contain managed code.
New pages added to the web UI project also show the same behavior (Didn't hurt to try)
Updates:
We've narrowed down the problem to a single assembly. It's a wrapper for a third party web control. I'm looking into replacing it, we'll see if it fixes the problem.
http://support.softartisans.com/kbview.aspx?ID=1318
Turns out it was an issue with the vendor control. Wish their solution actually worked though...
Try to re-register ASP.NET:
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
The typical command line syntax would be to command line to the ASP.NET 2.0 version of your framework and type:
aspnet_regiis -i
Are you using the "Classic" Pipeline Mode for your Application Pool. The "Integrated" one is the default in IIS7 and it introduced changes in terms of configuration. (One example is HttpHandlers that need a different configuration in web.config).
The "Classic" one mimics the IIS6 application pool, and should work with the same configuration as for IIS6.
If you prefer to use the Integrated Pipeline, there are some tools that will automatically try to convert you configuration files.
Scott Hanselman covers some of these tools in his blog post.
I'm using Visual Studio 2005 on a Windows XP SP3 machine and recently have come accross a some what strange issue.
I have a C# and ASP.NET project that runs fine when on the team test server and using IIS locally on my own machine. However, running it using the in-built Visual Studio ASP.NET Development server it doesn't seem to serve all the images/scripts/css files all of the time. When I load a page one time images A, B and C will be missing and I may get a system (sub-package) error however loading it again all those images will be there and the sub-package will work but a CSS, a script or any other image file may be missing.
The Windows event application log seems to show occasionally the missing files will be logged but this isn't consistent either.
It happens to me all the time; I think the reason is that the ASP.NET Develoment server is not a very good HTTP server, and when receiveing too many requests, it drops some ones.
Since it is also very very slow, I configured vs2008 (you can do that with vs2005, of course) to use ASP.NET for debugging; it works far better that way.
To do that:
Project -> properties -> Web (last tab) -> Server. There are three alternatives: Use Visual Studio Development Server; Use local Web IIS; Use custom Web server. Choose the second. (not sure about the exact english names: I have the Italian version of VS).
Check the page in Firefox/Firebug or with IE8 and see if the paths to the files/scripts/images is correct or not. A common problem when switching between the local dev webserver and IIS hosted pages is that the paths may not resolve the same. You can fix this sometimes by using the "~" character before a path in the asp code.