I am using dotnetCHARTING: the dll is installed in the GAC and referenced in my web.config (all versions appear to match). The project has a reference to the dll.
web.config:
<add assembly="dotnetCHARTING, Version=5.3.3540.17054, Culture=neutral, PublicKeyToken=af2cd47db69d93bd"/>
The site code compiles ok, but all aspx pages using the charting library complain that the Chart tag does not exist (warning that it might be a compile error). The aspx pages do not render the charts.
Each page has a reference to the assembly:
<%# Register Assembly="dotnetCHARTING" Namespace="dotnetCHARTING" TagPrefix="dotnetCHARTING" %>
Does anybody know what could be causing this?
Thanks a lot for any help - I'm quite desperate to get this resolved.
Ryan
I think, next article explains everything.
http://www.devexpress.com/Support/Center/p/Q261123.aspx
You must download and install MsChart from Microsoft
Here's the download link:
http://www.microsoft.com/downloads/details.aspx?FamilyId=130F7986-BF49-4FE5-9CA8-910AE6EA442C&displaylang=en
Related
I have an issue I can not, for the life of me, figure out.
We have an MVC4 app and on a (in fact now I believe it's the only) remaining .aspx page, there is an error in the master page: The name 'Scripts' does not exist in the current context
The line in question is this one: <%: Scripts.Render("~/bundles/Library") %>
This bundle is referenced successfully on every other page. To make matters worse, this issue only happens in production (works fine on my local machine, dev server and UAT server). We've only just added bundling to the project, so obviously this issue didn't come up before our latest release.
I have done some googling (a fairly drastic understatement), but can't seem to find the answer.
Help me Obi-Wan Kenobi, you're my only hope :).
Ensure
<add namespace="System.Web.Optimization" />
is in the web.config. This is needed in order to use the Scripts helper.
I'm walking through the Series on "How to use charts with ASP.NET" (Scott Michell). Somewhere, he says:
...Both of the above configuration additions are automatically added to Web.config when you add a Chart control to a web page for the first time in your project...
I've checked on my web.config, but I didn't see anything. So, I manually added them. Now, when I try to run the program, I get the following error:
...The server tag 'asp:Chart' is ambiguous. Please modify the associated registration that is causing ambiguity and pick a new tag prefix...
Line 4: <%# Register Assembly="System.Web.DataVisualization, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"...
It looks like things are working the way the author said. But, How do I know that a configuration is set up if I can't see it on my web.config file? Do I need to run first into an error?
Thanks for helping.
http://support.microsoft.com/kb/2023215
This explains that the page directive isn't needed any longer when moving to 4.0 version of the chart control dll.
I have a VB Web Site project that has recently (and mysteriously) stopped importing the "System" namespace by default.
I'm having to either place an Imports System line at the top of each code behind, or preface everything with System, which is fairly annoying, not to mention redundant. I can't for the life of me figure out how to get the System namespace back to being imported by default.
I've already checked to see that WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config contains the <add namespace="System"/> line--it does. That was my best lead.
I have references to several namespaces within the System namespace in the <assemblies> node (e.g. System.Design, System.Web.Extensions of my website's web.config. There is no <namespaces> node. This has not been changed recently.
I'm tearing my hair out. Does anyone have any suggestions?
This seems to have fixed itself as mysteriously as it broke in the first place. I'm not sure what I did, but it's working now. So it goes.
Just been through this with a VB Web Project in VS 2013.
Lots of cases of the error from types in the System, System.Collections1, …
Turns out when copying a <configSections> element into the web.config (as part of adding some better logging) I'd copied the surrounding <configuration> element in as well.
Lots of weirdness followed. Was able to find issue when I found I could get the site to run and the IIS error page told me I had a configuration error.
Now to redo all the changes I had undone on my way to finding that….
1 The wonders of legacy code maintenance.
I have the following definition at the top of my .ASCX file:
<%# Control Language="C#" AutoEventWireup="true" CodeBehind="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %>
In that control I make use of <%= %> blocks to refer to members that I've declared in the code-behind file. If I compile and deploy the control, it works fine. But in Visual Studio I get a lot of design-time errors, "{some variable} does not exist in the current context." And Intellisense breaks too: it works for members of UserControl, but can't find my own declared members. There are other issues as well. In general, everything points to the fact that the ASP.articleview_ascx class getting generated is somehow not inheriting from the MyNameSpace.ArticleView class.
I've found that if I switch the CodeBehind attribute to "CodeFile":
<%# Control Language="C#" AutoEventWireup="true" CodeFile="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %>
suddenly Intellisense works and all the design-time errors disappear. But I don't want to do runtime compilation, or deploy my .ASCX.CS files - so I can't use CodeFile.
I've checked the simple stuff, like making sure that my CodeBehind filename is correct & the Inherits class has the proper namespace, etc. (And since it works properly after changing the attribute to CodeFile, those must be pointing at the right place....) But what am I missing? Why can't it handle the CodeBehind attribute?
Thanks,
Steve
Update: from a thread below - basic question was, why not just use CodeFile? Answer: when I try to deploy using CodeFile= in my files, after deploying I receive the following stack trace (presented in its entirety):
/_layouts/Pages/ViewPage.aspx.cs' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.UI.TemplateParser.ProcessCodeFile(VirtualPath codeFileVirtualPath) at System.Web.UI.TemplateParser.ProcessMainDirectiveAttribute(String deviceName, String name, String value, IDictionary parseData)
(This is from a request to /_layouts/Pages/ViewPage.aspx. ViewPage is the page that has several other controls including the ArticleView mentioned in my original example. It just happens to be the first file that fails - if I go back to CodeBehind= in ViewPage, then included ASCX with CodeFile= will fail in the same way.) This seems to be the page compiler complaining because the inherited codebehind class can't be found in any loaded DLL, so it expects there must be a CS file to do on-demand compilation.
The issue here is that I don't want to deploy CS files, just ASPX/ASCX. Having read through many articles like this great one I'm aware of the various new models of deployment, although I've never used anything but a Web Application Project (converted forward from VS2003, we were late adopters of 2005 & the WAP model had already been added by the time we switched up from 2003.) Over many VS2005/8 projects, I've never had a problem with CodeBehind=, until this Intellisense issue showed up... though it doesn't help that in this case I'm deploying to SharePoint, which introduces a whole new level of complexity.
Since I've not deployed using CodeFile before, it's very likely that I'm missing some option I'm supposed to set in VS when building, in order to force a pre-compile. I just need to be able to deploy, as I do today, as a set of ASPX/ASCX with a single codebehind DLL. And that's working today with CodeBehind= ... it just has the originally mentioned Intellisense problem, which is really what I want to fix :)
Will post more as I identify what files might be relevant to the question...
Have you checked the Build Action on your project files? I have duplicated your issue by setting the Build Action on ArticleView.ascx.designer.cs to None. I can also compile when using CodeFile, etc..., I'm 99% sure that's your problem.
You are missing the [your-file].ascx.designer.cs file, which links your controls to your codebehind.
Just like CitizenBane suggestions, you need to right-click the file (or folders, or entire web project) and select "Convert to Application". Visual Studio will examine your ascx/aspx files for the server controls, and generate that designer file for you.
I actually ran into this myself, on a far larger scale... C#: How to convert a Website project to a Web Project
Check the answer.
This has happened to me before. Try right clicking the ascx/aspx and click on "Convert to Web Application". You may just be missing the generated controls. If you don't see it in the context menu, delete the designer generated file first.
CodeBehind is deprecated in .NET 2.0. I believe that only <= 1.1 uses "CodeBehind". Now it is "CodeFile" as you say.
Why do you not want to compile your code? If you compile you don't have to deploy your .cs files...
Why do you have the code behind for your ascx control as an aspx named page code behind?
A UserControl (ascx) usually has a codebehind of
CodeBehind="ArticleView.ascx.cs"
instead of what you have listed
CodeBehind="ArticleView.aspx.cs"
Notice the aspx instead of the ascx for a User Control.
That could be your problem... a simple typo or a copy and paste error. Couple possibilities come to mind:
Maybe you have the ascx control (User Control) specified above using a code behind file that is inheriting from System.Web.UI.Page instead of System.Web.UI.UserControl (that could be causing the Visual Studio errors).
You have the UserControl pointed at the code behind for a same name aspx page. Similar problem as #1 which would cause Visual Studio to get all confused.
Your files are name ArticleView.ascx and ArticleView.aspx.cs. This might confuse Visual Studio since I believe VS might expects a particular naming convention.
For a User Control (ascx) your files should be named:
ArticleView.ascx (CodeBehind="ArticleView.ascx.cs" Inherits="[NAMESPACE].ArticleView")
ArticleView.ascx.cs (inherits from System.Web.UI.UserControl)
ArticleView.ascx.designer.cs
For a Web From (aspx) your files should be named:
ArticlePage.aspx (CodeBehind="ArticlePage.aspx.cs" Inherits="[NAMESPACE].ArticlePage")
ArticlePage.aspx.cs (inherits from System.Web.UI.Page)
ArticlePage.aspx.designer.cs
This just happened to me in VS2010 after upgrading a web application project to .net 4.0.
The answer was to make sure you have targetFramework="4.0" set on the system.web/compilation section in web.config
i.e.
<system.web>
<compilation debug="true" targetFramework="4.0">
</system.web>
I am using the AjaxControlToolkit in VS2005, and it works fine. I do have some issues though, when I go to some pages I have, then click back, I get this JavaScript error:
'AjaxControlToolkit' is undefined
I have searched MSDN forums, and google, and tried many of the solutions, but none have worked. I have tried, EnablePartialRendering="true", and others. Short of rewriting everything and changing the workflow of my application, is there any way to find the root cause of this, or fix it?
I got this problme fixed but not by setting CombineScripts="false" but by using the solution described in this post.
There have been some changes in the latest version, due to which you have to use Sys.Extended.UI.BehaviorBase instead of AjaxControlToolkit.BehaviorBase in the registerClass call.
To get around this 'AjaxControlToolkit' is undefined Error, you may also want to ensure that you have CombineScripts set to false in your ToolkitScriptManager configuration. This can be found in your Master page and this solution has worked for me.
<myTagPrefix:ToolkitScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="true" EnablePartialRendering="true" SupportsPartialRendering="true" **CombineScripts="false"**>
Note you will want to change myTagPrefix to the tagprefix you are using for AjaxControlToolkit. This is usually defined in asp at the top of an aspx file like this...
<%# Register assembly="AjaxControlToolkit" namespace="AjaxControlToolkit" tagprefix="myTagPrefix" %>
This may be a silly question, but did you double check to make sure you have the toolkit reference at the top of your aspx file?
(Adding from comment for ease of reading)
Try adding this to your web.config
<system.web.extensions>
<scripting>
<scriptResourceHandler enableCompression="false" enableCaching="false" />
</scripting></system.web.extensions>
Is that a javascript error?
I suppose it has to do with back-button support in the toolkit.
And undefined errors mostly occurs because somehow the script that contains "AjaxControlToolkit" doesn't gets properly loaded.
Thing that come to mind:
The order scripts get loaded, does the Toolkit gets priority?
When there are errors in any of the loaded scripts all the other scripts that hasn't loaded yet will simply be canceled and not gets loaded.
See the outputted HTML of the problem page, find links to all the AXD files and make sure you can download them and see valid javascripts inside.
And if you don't already, get Firefox and Firebug and you should be able to trace to the actual script line that emits the error.
Hope this helps.
As [CodeRot] said you need to ensure you have all the AJAX web.config extensions in place, this is the most commonly missed point when doing ASP.NET AJAX sites (particularly from VS 2005).
Next make sure that you have a ScriptManager on the page (which I'm guessing you do from the "EnablePartialRendering" mention).
Make sure that you are referencing the AjaxControlToolkit version for your .NET version, it is compiled for both .NET 2.0 and .NET 3.5, and I believe the latest release is only supporting .NET 3.5.
Ensure that you're getting the Microsoft AJAX Client Library added to the page (that you're not getting any errors about "Sys" missing).
Ensure that you a registering the AjaxControlToolkit in either your ASPX, ASCX or web.config.
If nothing still hasn't worked out for you. Verify that you are not caching this ascx/aspx. Remove the OutputCache declaration.