The MvcReCaptcha library looks very solid, and appears to have some good developer adoption, but when I tried it for the first time today, using the supplied HTML helper, my app won't run. I have the helper in a partial view as follows:
<fieldset>
<legend>3. Verify that you are a human.</legend>
#Html.GenerateCaptcha()
</fieldset>
I have the namespace included in web.config as instructed:
<pages>
<namespaces>
<add namespace="System.Web.Helpers" />
<add namespace="MvcReCaptcha.Helpers"/>
</namespaces>
</pages>
(Other namespaces removed for brevity)
And I have my private and public keys defined in appSettings. I can see no way that I deviate from the examples on the CodePlex page except that I am using Razor. Can anyone offer some insight into what I may be doing wrong?
If you are using Razor you need to add the MvcReCaptcha.Helpers namespace to the <namespaces> section of ~/Views/web.config file and not the one in ~/web.config.
Related
A user control that was working is no longer being picked up in the ASPX file.
ASPX File
<%# Register TagPrefix="Uc1" TagName="ContactForm" Src="~/Controls/VFEmailForm.ascx" %>
<uc1:VFEmailForm ID="VFEmailForm" runat="server" />
It was working but now isn't. A green line appears under the uc1:VFEmailForm and when you type Uc intellisense doesn't show Uc1. It is as though the register statement does not work - well it obviously doesn't. This was all working prior to upgrading to Visual Studio 2015.
I've shown part of my web.config file as ancient posts have suggested this may be the cause.
Web.config
<pages>
<namespaces>
<add namespace="System.Web.Optimization" />
</namespaces>
<controls>
<add tagPrefix="webopt" assembly="Microsoft.AspNet.Web.Optimization.WebForms" namespace="Microsoft.AspNet.Web.Optimization.WebForms" />
<add tagPrefix="ajaxToolkit" assembly="AjaxControlToolkit" namespace="AjaxControlToolkit" />
</controls>
</pages>
If there is a guru out there who can fix this I would appreciate it.
I had the same problem when building under x64. I switched to x86, rebuilt the project and VS 2015 worked as expected.
I was also in your situation a bit time ago.
1 .Try using the same tag name in both lines :
As in your case
<%# Register TagPrefix="uc1" TagName="ContactForm" Src="~/Controls/VFEmailForm.ascx" %>
<uc1:ContactForm ID="VFEmailForm" runat="server" />
If it helps then ok, otherwise after making this change , try restarting the visual studio.
This procedure helped me out.
I use Visual studio 2017, and faced a similar problem: Having green, wavy lines under the tagName instead the whole line, i.e., <Uc1:***ContactForm*** ...>. As part of this, I was getting this error:
Element ContactForm is not a known element.
A solution posted by #mitoutsnd on ASP.NET solved the problem by suggesting that I use:
Build > Rebuild Solution
This solved my problem.
I have an MVC application which I am deploying out to a staging server using Team City. I have created a Web.Staging.config transform to handle the different database connection, certificates and service calls.
On this staging server I have had a request to have the title of the Index view to read "TEST SYSTEM" and to have a different colour scheme to signify, at a glance that the user is on the test system.
So far I have handled this by changing the view on the file system in notepad, and swapping the bootstrap.css file to one with a different theme however every time I do a new commit/deploy these changes are wiped and its becoming tiresome.
Is there anyway to handle CSS/view changes per server by using a similar transform system as employed to handle the web.config
There's not really an easy way to transform CSS files like that, but what you could do is have your master CSS file link in your config file, so your view would be something like:
<link href='#ConfigurationManager.AppSettings["MainCSS"]'>
Then your web.Debug (and other transformations) could point to the correct path:
<add key="MainCSS" value="/Content/Site.css" />
And your web.Staging config could point to another:
<add key="MainCSS" value="/Content/Staging/Site.css" />
You can also apply the above logic for your Index view:
public ActionResult Index()
{
string viewName = ConfigurationManager.AppSettings["MainView"];
return View(viewName);
}
Then have in your web.Debug (and others):
<add key="MainView" value="Index" />
And in your web.Staging:
<add key="MainView" value="IndexStaging" />
One solution could be to add a key to the web.config and read it using the WebConfigurationManager.AppSettings. Those settings can be transformed. In your view you can check this setting if you need to change the title and if you need to load an additional css file.
In your web.config:
<appSettings>
<add key="IsTestSystem" value="False" />
</appSettings>
and in as transform:
<appSettings>
<add key="IsTestSystem" value="True" xdt:Locator="Match(key)" xdt:Transform="SetAttributes"/>
</appSettings>
In your view / layout:
if (Boolean.TryParse(WebConfigurationManager.AppSettings["IsTestSystem"] ?? "False", out run)) {
// include css file for test system or modify the title
}
And, if you want, you can just switch between the two bootstrap.css files.
I'm not talking about javascript functions, but server side functions written in c#.
For the html table in my view, I'm creating table headers that act like sortable columns. But the sortability depends on a complex logic so I want to put the logic into a function instead of writring it for each column.
#Amr ElGarhy
Thank you for suggesting customer helper, but the helper class I create is not being regonizied.
Helper Code:
namespace MyHtmlHelpers
{
public static class CustomHelpers
{
public static string MySortColumn(this HtmlHelper helper, string label, string col, string dir, UrlHelper url)
{
return string.Empty;
}
}
}
web.config:
<pages>
<namespaces>
<add namespace="System.Web.Helpers" />
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="System.Web.WebPages"/>
<add namespace="MyHtmlHelpers"/>
</namespaces>
</pages>
But in View, neither #HtmlHelper.MySortColumn nor #Html.MySortColumn is regonized. Am I missing something here? I even restarted my pc.
UPDATE
adding namespace in web.config didn't work for me. adding in View page works.
I think you need to take a look at HTML Helpers and how to create a custom one:
http://www.asp.net/mvc/tutorials/creating-custom-html-helpers-cs
http://www.asp.net/mvc/videos/how-do-i-create-a-custom-html-helper-for-an-mvc-application
Try this
helper syntax
It's better to create base class with the logic and derive your views from this class. Normally you shouldn't reveal/share any methods to reuse between views.
Are you using areas? Areas have their own view folder and usually have their own web.config. If that's the case, you can try to add namespace to that web.config.
Also, web.config files are resolved hierarchically through folders. It means you can have web.config in your base Area directory which affects all area specific views.
In my case, I have two web.config files where I add my namespaces - one is in View directory and other one in Area directory.
In my code behind, I can do the following in the onload:
string x = Fmg.Cti.UI.Utilities.Classes.ResourceController.ReadResourceValue("Riblet", "Riblet_Chicklet1_Button_text");
This works without issue.
In my aspx page (I didn't remove the code from the onload), I put this:
<%= Fmg.Cti.UI.Utilities.Classes.ResourceController.ReadResourceValue("Riblet", "Riblet_Chicklet1_Button_text")%>
When I do, I got an error:
error CS0234: The type or namespace name 'Cti' does not exist in the
namespace 'Fmg' (are you missing an assembly reference?)
I had this (or something quite similar) working. I don't know how I broke it.
Thanks again for your help.
You need to register the assemblies you're using in your page as well (just like usings in your code behind). See Do I have to add "<%# Register assembly=" to every page?
Do you have that namespace imported? For asp.net you can do something like the following to make namespaces available for inline coding.
<%# Import Namespace="Fmg.Cti.UI.Utilities.Classes" %>
You can make namespaces generally available to all of your asp.net pages for inline coding by adding the namespaces into the web.config
<system.web>
<pages>
<namespaces>
...
<add namespace="Fmg.Cti.UI.Utilities.Classes" />
...
</namespaces>
</pages>
</system.web>
I am getting the error below when trying to build the web site project in Visual Studio 2010:
The page '/WebSite/controls/C2.ascx' cannot use the user control '/WebSite/controls/C1.ascx', because it is registered in web.config and lives in the same directory as the page.
I have 2 web user controls:
controls/C1.ascx
controls/C2.ascx
The controls have been registered in web.config:
<configuration>
<system.web>
<pages>
<controls>
<add src="~/controls/C1.ascx" tagPrefix="my" tagName="C1"/>
<add src="~/controls/C2.ascx" tagPrefix="my" tagName="C2"/>
</controls>
</pages>
</system.web>
</configuration>
C1.ascx contains just a static HTML, C2.ascx is trying to include C1:
C1.ascx contains just some plain static simple HTML. C2.ascx is trying to include C1.ascx:
<%# Control Language="VB" %>
<my:C1 runat="server" />
<p>Hello from C2</p>
When trying to build the project, I am getting the error message at the top. I realise this issue can be fixed by adding another Register directive to C2.ascx...:
<%# Register Src="~/controls/C1.ascx" TagPrefix="ctl" TagName="C1" %>
...but I'm wondering if there's a cleaner solution and why am I getting the error in the first place?
Your only possible solutions are to:
Move the control out of the directory its currently sharing with outer.ascx, or
Re-register the control inside of the outer.ascx like you already mentioned
Re-write them in code as controls in a separate library
I personally think moving is the easiest, if it will work for your solutions. Second would be re-registering, even though annoying. Abstracting them out into a full code library is probably not worth the effort if this is the only reason you are doing it.
You could also put the controls into different folders. But I don't think this is much cleaner or better.
BTW: this behavior is by design, as you can read on this MSDN page (look for the yellow note almost at the end of the page).