I wanted to switch to the beta version to see if it fixes a problem I have been having, so I downloaded it and put two dll files into my bin folder. I deleted the old references to these files in visual studio, and re-added them.
When I run my program I get an error:
Microsoft JScript runtime error: AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the AjaxScriptManager in System.Web.Ajax.dll, or use the ToolkitScriptManager in AjaxControlToolkit.dll.
I can't figure out how to fix this. I have the new System.Web.Ajax.dll added to visual studio, but I can't see any AjaxScriptManager anywhere...
Any ideas?
Adding the following to the aspx file fixed this error for me:
<asp:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server">
</asp:ToolkitScriptManager>
I had very bad performance issues when trying to use ToolkitScriptManager from ASP.NET Ajax Library Beta 0911 library.
The problem was that PreRenderComplete stage took over 0.5s for a simple form.
When I switched to AjaxScriptManager (from System.Web.Ajax.dll found in the same Toolkit release), the same application started to work 10 times faster and PreRenderComplete stage now takes 7ms (up to 70 times faster!).
So I suggest using AjaxScriptManager instead of ToolkitScriptManager if that doesn't break any functionality of your application.
<ajax:ToolkitScriptManager ID="somename" runat="server" EnablePartialRendering="true" CombineScripts="false"></ajax:ToolkitScriptManager>
Use the above code to turnoff the combinescripts feature of ToolkitScriptManager and you wont get error.
Thanks, SK
Related
I have a ASP.Net 4.0 site that I am editiing in VS2010. Every # Master and # Page tag has the blue squiggle lines giving the following error:
ASP.NET runtime error: Could not load file or assembly 'Interop.CertEnroll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I know it is related to trying to load a 32bit dll into a 64bit application but I am not sure how to control it since I am not sure how this Iterop.CertEnroll client is evening being referenced.
I am targetting Any CPU for my builds.
My application still functions but it bothers me to see all of these warnings and I have seen hints that this may be causing issue with my AjaxToolkit server tags not being recognized.
Thank you!
Karl
I discovered this solution for you. Since I cannot reproduce the error, can't exactly say if it would resolve the error for you, but you can still try. Here is the crux of the story from the link:
If you compile against x86 platform instead of Any CPU platform (which makes the code to run against x64 platform on x64 systems by default), it will work fine.
All the best!
Make sure you are compiling against .NET 4 and not .NET 4 Compact Framework.
I had the same issue not long ago with this missing dependency.
Installing Microsoft Online Services Sign In provides the correct assembly, although I'm not sure why this would be required.
edit: I can't seem to find the article that pointed me to the above download.
This is a known bug they aren't going to fix. You can try suggested workarounds though.
TL;DR: Check your master page(s) if the ContentPlaceHolder tags are specified correctly, and your pages to see that the ContentPlaceHolder tag ids are correct.
Long answer:
For anyone facing this issue and if the other solutions do not work, here is another thing you could try. I was getting the same error, with all master and page tags highlighted with the error:
Could not load file or assembly Microsoft.Practices.ServiceLocation,
Version=1.3.0.0
My packages were all in order and I spent quite a lot of time trying to get it to work. Turns out the error was misdirecting and the actual error was missing ContentPlaceHolder tags in my nested master page.
Our application registers events OnInit. When developers create a new aspx file from the visual studio template, it has AutoEventWireup="true". This leads to event handlers being registered twice and run twice.
Is there an easy way to cause the compile, build or other post build step to fail when the directives are set "wrong".
I'm using Visual Studio 2010 and TeamCity. I'm open to running any technology as a postbuild step.
You could precompile your site. Precompiling involves compiling the aspx and ascx files aswell as the .cs. It will make your site faster and it ensures things hook up a bit better, the downside is you cant change the aspx or ascx after you have compiled them.
http://www.dotnetperls.com/precompiled
This SO page describes a couple of ways of doing it
Compile Views in ASP.NET MVC
You could try integrating StyleCop with TeamCity, and create a custom StyleCop rule that checks for this. Not sure how difficult it would be, but it's what comes to mind. See this question about using StyleCop with TeamCity.
Also, as suggested by Erix, update your templates to prevent this from being the default behavior.
I'm jumping into updating an ASP(.NET) website coming from a PHP background and am trying to get my bearings. I think it's ASP (not .NET) since the code is not compiled and it seems to be using ADODB, but I'm really quite clueless.
So, how can I tell if the code I'm working with is ASP or ASP.NET? Bonus points if you can tell me how to know what version of ASP(.NET) I'm working with.
ASP file extension is .asp, whereas ASP.Net has .aspx.
ASP files contain VBScript code between <% and %> tags, and may start with
<%# Language=VBScript %>
ASPX files start with the line
<%# Page Language="C#" AutoEventWireup="true" CodeBehind="pagename.aspx.cs"
Inherits="webname.pagename" %>
and typically contain components marked by tags such as < asp:Label ... >
and have a code-behind file called .aspx.cs or .aspx.vb.
What everyone said before is quite all you need to know to differentiate between ASP Classic and ASP.NET.
As for versions, ASP Classic is most of the time 3.0, and this is probably what you have if it is classic.
For .NET, openning a .csproj or .sln file in Visual Studio (if such exists) is the fastest way to find out - just go to the project properties and see what framework it is targeting. System.Environment.Version.ToString() might give you that, but it might not.
You'll need to look for some language characteristics that weren't supported in earlier versions to know it is a certain version. For example, LINQ (SQL'ish code syntax) only exists for 3.5+. The keyword "var" wasn't used often in 2.0. And so on.
An asp.net site would have its files ending with .ASPX and asp would just have .ASP.
Now in ASP.NET you can have "code behind" files that would appear as a file with ".aspx.cs" (when in C#) or ".aspx.vb" (when in visual basic), but not necesarly; you could have the code inside the ASPX pages.
Maybe if you post a snippet of the code that you're looking at we can give you more info
What language is used in the files? If it is something ending in "script" then it is likely classic ASP and not ASP.Net, assuming you can see what language is used in the files. The extensions are usually different but this can circumvented by changing how IIS handles various file extensions.
As a first basic step, shouldn't it be as easy as checking the file extension? But there is an interesting but old article at this link http://www.codeproject.com/KB/aspnet/ASPNET_vs__ASP.aspx which goes in a little detail.
About the version, you may get the version using System.Environment.Version.ToString()
I'll be debugging a site in Visual Studio 2010 and editing an *.aspx or *.ascx file, and without warning, it will lock up so that I can't edit it. There's no message or anything, I just can't type or make any changes.
The only way to start editing again is to stop debugging, close the editing window, and then find whatever file I was working on and reopen it. It's a huge pain in the you-know-what.
My colleagues are experiencing the same thing, so it's apparently not something with my particular setup.
What's the explanation, and how can we make it stop?
Note 1: I've reported this to Microsoft here. If you've experienced this as well, please go there and vote up the bug report.
Note 2: This is not VSS-related, at least in my case. We use VisualSVN, which doesn't use file-system-level locking to mark files as checked out.
Finally Microsoft came with a solution this year, you can download the fix here:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=40811
I've found a temporary workaround-solution:
Right-click on the file and select "Open with...". Now select "Source Code (Text) Editor" and you can edit the file again but without IntelliSense :-( But you won't need an external editor.
Nevertheless we still have to wait for Microsoft to find a better solution.
As a workaround I use "Browse With..." (Right click in Solution Explorer) to load and view the page(s) when I'm making HTML refinements. You can't debug code of course but it doesn't lock the files so it makes the problem a little less irritating when making design changes.
I have replicated this issue with Windows 7, XP, both with and without source safe, MVC projects, web application projects and website project also with and without 'edit and continue' enabled i.e. I can edit the code but NOT the ASPX markup when using edit and continue!
I experienced the same issue, and found out that for me it occurred only in .aspx pages with an "eval" statement (used for databinding within e.g. a gridview) within <a> tags. As soon as I removed the "eval" statements, the pages became editable again while debugging.
Example of code causing the page to be readonly while debugging:
<a href='<%# Eval("URL") %>' target="_blank"
title='<%# Eval("URL", "Open url: {0}") %>'><b>'<%# Eval("Text") %>'</b></a>
Example of replacement code causing the page to be editable again while debugging:
<asp:HyperLink NavigateUrl='<%# Bind("URL") %>' runat="server" ID="hlURL" Target="_blank"
ToolTip='<%# Bind("URL", "Open url: {0}") %>' Text='<%# Bind("Text") %>' Font-Bold="true" />
I was just having the same problem. When the code page disappers, I click debug->restart. It restarts the debugging process, and show all the pages I had open.
Usually this is because of your version control system making the files readonly (namely VSS). Go into the settings for source control and set the editor so that it will checkout files when edited.
If it is not your source control, then it is that the files are being made readonly by something, and that 'something' is what you need to find to fix this problem.
I get the same using VS2010, random file locks galore... however i find that if i close the file in question and re-open it i can continue editing i.e. i don't necessarily have to stop the whole program running.
Have you and your collegue got Microsoft Office 2007 or 2010 installed? Run the Office setup from CP > Programs & Features and do a Repair. Reboot afterwards, or at least log out.
I'd understand if you don't want to do a full reinstall of Office, but if the repair doesn't fix this, I would suggest it.
Using "devenv.exe /resetsettings" will restore Visual Studio back to its original factory state.
You can also use "devenv.exe /log" to log Visual Studio activity for troubleshooting:
http://msdn.microsoft.com/en-us/library/ms241272.aspx
I can tell you it is known bug.
It always happen when you edit on CSS or Javascript in Code View.
I have report to MSDN forum and Microsoft Connect, but it seems it is rare bug,so not many people to solve that.
I have this problem and also have Resharper installed. Do those of you with the problem also have Resharper installed? I seem to have memory leaks in VS also that eventually bring VS to a crawl. Closing VS and re-opening it will fix the issue for a while. I have always assumed this was related to Resharper. Thoughts?
Try refreshing project containing that file, from the solution explorer. That should re-enable editing.
Had the same problem with VS2010. R-click on the ASPX file and select the XML EDITOR -- then editing is enabled.
I can get an UpdatePanel control working(partial postbacks) no problem with a new fresh .net 3.5 project. I've overcome many of the pitfalls that are answered here on this site. (scriptmanager on the page, using triggers, or placing the button within the panel itself.)
If I have try to use the UpdatePanel on a project that was originally a .net 1.1 project, upgraded to 2.0, now recently upgraded to 3.5, I can't get partial post backs for anything. At this point the code is exactly the same within the form. My relevant web.config parts are the same, and from what I can tell my .proj files too are the same.
Anyone have any ideas here?
Have you checked to make sure you aren't still caching the assemblies? I know the AJAX control toolkit required you to "copy local". Make sure you eliminate that as a possibility.
I've checked, and the copy local is set to false on all references. Any other check to see if caching is a problem?