This is strange and baffling. In my ASP.NET 2.0 app I have a form that uses a number of client-side validators. Custom, Regularexpression and RequiredField. My app requires that I enable or disable certain validators based on a dropdown selection. I do this in my codebehind event. All this works great in my dev environment however when I deploy to the server it does not. Mainly when I run the app from the server it will not allow me to enable or disable the validators in code. When I set the enabled property in the aspx file it remains in that state regardless of what I do in the server event. Again - this works perfectly in dev. Any suggestions? Could it be the version of .NET 2.0 is different on my dev machine and the server? I am at a loss and we are heading for production soon. Please help!
This turned out to be a .NET version issue. Once I applied the 2.0 Service Pack 2 on the server my problems went away.
Do the validators work at all on the production machine? That is, do they prevent you from entering invalid data?
I have a vague recollection of something like this happening to me. It may have been an issue of the JavaScript file needed by the validators not being sent from the server. Do a View Source, or turn on debugging (FireBug or IE8's F12 command). See if you're maybe getting JavaScript errors you didn't know about.
Related
I am supporting an application written in classic ASP with IIS 6.0 on Windows Server 2003. I have NO priviledges to add or configure any of the software on this purely development use server, so I cannot install any 3rd party tools. I have requested and requested Visual Studio, but the system admin is old school and says we don't need that for classic ASP development. So... we're stuck with Notepad and IE 7.
The sys admin says that both client-side and server-side debugging is turned on in IIS and that IIS was restarted after the change. However, I can't get any response from the script debugger when I insert a stop statement or a 1/0 expression. (I do get appropriate error messages on the page - just no debugger.)
I have both checkboxes cleared in Internet Options/Advanced so IE and Other debugging will be allowed.
What else do I need? What am I missing? Maybe the script debugger isn't installed? How can I tell?
You are going to have to modify the script to output your own debug information to the browser.
You can't STOP server-side code using this technique, but you can spit out the value of any data to variables you think are relevant to solving the problem. If you're worried about users seeing the debug code you can wrap the output in HTML comments <!-- ... --> and view the page srouce.
I have made some changes to a view in my ASP.NET MVC3 application, but the changes I have made are not showing up when I test/debug the site within the browser. The changes I am making are simple text amendments to the markup.
I am using the Visual Studio development server for testing the application.
The odd thing is, I have tried publishing these changes to IIS and the changes I have made to the view are working when I test the application using the IIS server.
It is only when testing in the Visual Studio environment that this seems to happen.
Thanks,
A common problem i've run into is when you are not using IE and you close the debug session, but not your browser.
This means that the "IIS/development server" is still running in your system tray, but it is running on the old compiled code, if you hit ctrl + shift + b, you build your entire solution and re-publish your code to your development server. this allows you to hit refresh (F5) in your browser and the changes you've made to the razor view should now be reflected in your browser.
Are you using IE? Maybe deleting the cache or using another browser should work? I've had a lot of problems with that :D
Solution is to use IIS Express. For some reason, the VS development server doesn't recognise changes to code behind - nothing to do with caching on the browser.
However the location of the source code as suggested in other answers is important - it works for me using the c:\windows folder or c:\users\DefaultAppPool - apparently it has something to do with security to ensure.
Only applications running under the 'DefaultAppPool' identity are permitted under IIS. So, for anyone using a VM and mapping the host OS code folder you won't be able to rectify this unless you copy to a local folder in the c:\users\DefaultAppPool folder.
You may also now have difficulties accessing the SQL server database established for the Membership Provider under ASP.NET. For more details on how to fix that, I've posted on my blog.
Basically we have this aspx script generated by another company, which we need to run, we normally just use coldfusion, for our company.
However this app is an aspx.
We have both a development and production server, it works flawlessly on our dev server, but it fails to work at all in the production server.
It uses a javascript function called _doPostBack.
I have compared the aspx files on dev/prod line by line, and they are 100% identical.
So I need some ideas what iis7 setting to change to allow this to work. Since we didn't do anything special to make it work on our development server.
Our Prodution server is sql2008, iis7, win 2008 i believe.
Our Development server is sql 2005 express, iis7, vista business edition.
Any suggestions or tips we can do?
And in firebug it generates no javascript errors of any code, but the navigation links do nothing.
The page itself displays, on the left is a list of links, which if clicked on, should change the content on the right/main content area.
This works fine on dev, it doesn't work at all on production. It does display the page, show's no javascript errors, but the navigation links do not work.
There is no external javascript file, so it must be something in iis.
Thanks
I would consider reinstalling asp.net on the box that isn't working. Can be done from command line using aspnet_regiis -i
http://msdn.microsoft.com/en-us/library/k6h9cz8h.aspx
Other than that I have no idea. Sounds like a config issue to me though..
In the IIS settings, make sure the ASP.NET System Services is running and verify that ASP.NET exists in the Role Services. Also check the Application Pools and in the Advanced Settings, you can check the .Net framework version.
What happens if you try to acccess a page you create called test.aspx with plain text?
You can try running the page locally on the production server, sometimes things will work locally but not remotely if it's an IIS issue.
Have you verified that the appropriate .Net framework is installed on the machine and that the page resides in an application in IIS?
Using IE8, press F12 to bring up the developer tools. Inside the tools you can examine the various scripts that are (or will be) running, and start debugging. Start the debugger and set a breakpoint where the _doPostBack function is being called (or inside the function itself) and see what is actually happening.
Also, you may want to fire up Fiddler2 and compare the HTTP requests between your development and production servers. It is entirely possible that something else isn't returning as expected (like a call to WebResource.axd) in production that works fine in dev.
I've built a web application that contains a page that uses the AjaxControlToolkit's TabContainer/TabPanel objects. I've developed a custom stylesheet, as well. I'm developing using Visual Studio 2010. The following is the behavior of my application:
VS2010 Development Server (localhost:XXXXX): Works as expected with the custom stylesheet.
Local IIS: The TabContainer rendered but the stylesheet wasn't applied. I fixed this by doing a CTRL+F5. It seems that IIS caches stylesheets pretty aggressively.
Remote Server: The TabContainer and TabPanel are completely hidden. Looking at the HTML, all of them have their visibility set to hidden.
The way I got my files onto my remote server were as follows (I haven't yet set up WebDAV or remote publishing because the server is a Windows 7 box and as far as I am aware does not support FrontPage Extensions):
The entire solution is under source code control (SVN).
Checked in all pending changes (including projects, aspx files, css, AjaxControlToolkit binaries)
Synced on the server.
Rebuilt everything on server.
Deployed to local IIS on server (which is externally accessible).
Both on the local IIS on the server and the development server on the server, the TabContainers are completely hidden. Looking at the SVN status on the server project, only the "AjaxControlToolkit.dll" is under source-code control. All the locale-specific DLLs are not on the server. Could this be a potential issue?
I'm not sure what's going on and would appreciate any help. Thanks!
Are you sure you are using the latest version of the toolkit? I had a visibility issue with the tabs the last time I upgraded a VS08 project to VS10.
Getting the latest version fixed that problem
Edit: Do you use the AjaxToolskriptManager or just the ScriptManager. You probably need the Ajaxone for most controls?
The issue was strange. I was setting the visibility of the active TabPanel to false programmatically in my code-behind. For some reason, on my development machine this didn't cause any problems but in the server machine, it did.
I am so used to attach a process when debugging ASP.NET application in .NET 2.0 and VS.NET 2005. I don't know what happened to this functionality in VS.NET 2008.
I also don't want to do debugging by starting from the start page because when the application is big enough you don't want it to be compiled and you sometimes cannot catch a case from start and you want to catch that case during that time.
I could't figure this one out.
I am running Vista Ultimate x64 with VS.NET 2008 Team Suite.
Also in the start options of the WebSite Propery pages Server is selected as "Use Default Web Server" and custom server is grayed out which I cannot check. (I don't know if I need some change here but I can't even try that)
On top of it, I tried debugging from default page but in that case what I got is "Unable to start debugging on the web server. Mixed mode debugging is not supported on Windows 64-bit platforms". What? Anyway I get into the configuration manager of the solution and changed the mixed mode to ANY CPU, however no luck.
Going without the help of debugging brings down ASP.NET to the level of PHP or other kinds.
Additional notes:
I am using DotNetNuke 5.0.1 and building modules under that.
IIS 7 is used with Integrated mode.
The key that I have found on 64 bit Vista for debugging is the following.
1.) Ensure that the web application is FULLY running in IIS and not Cassini (http://localhost addresses)
2.) When attaching to the w3wp.exe process, be sure to select the one with a type of T-SQL, Managed, x64 and NOT the one that shows a type of just x64
Following these two steps I have gotten around all of the issues that I have had. Similar to those you list above.
By the way, for anyone else finding this article based on the same error message (at least in my case) was to modify the app pool in IIS. Go to advanced settings, change "Enable 32-Bit Applications" to True. VS2010, Win 7 64 bit.
Okay, it sounds like you're suffering from a couple problems.
1) Automatic startup of the webdev server: This is usually caused by a project in your solution being set to "Always start when debugging". Simply click the project in the solution explorer and hit F4 to bring up the properties window, and change it from "True" to "False". You might need to check all the projects in the solution.
2) Attaching to a process should be done when the site is published to a real IIS, which I'm assuming you're doing. I'm not totally familiar with IIS under Vista, but you'll need to go into it and make sure that debugging is enabled for your web application. If you're doing this, you shouldn't need to bother with the Start Page or using custom servers.
Hope that helps some.
Help came from Mitchel Sellers.
He pointed out that the debug mode was ok however while attaching to the process, the "Attach To" was "Automatic:Native Code".
After changing to only "Managed Code" or simply by selecting "Managed Code" it started working.
Thanks Mitchel.
And here is the final words from Mitchel:
The "Script" option, is for classic ASP scripts, which ALWAYS run in 32 bit mode, thus debugging T-SQL and Script at the same time results in the "mixed mode", as T-SQL is 64 bit by default. Additionally without the "Managed" option selected, you would never be able to debug anyway.
Now, as to why it was different? I'm not sure, but once you change it you should be set to go for the future.