I have an ASP.NET application originally deployed to a .Net 1.1 Framework on Windows 2000 server which i'm now using on a Windows 2008 Server using 2.0.50727. We use the tilde (~) to resolve to an absolute path in many areas of the application and it works for things like asp:hyperlink controls (with run-at server tags), but for our bound datagrid controls which are using HyperLinkColumns to create links based on ID values returned from our database, the tilde is getting written to the page.
This code:
HyperLinkColumn oLink = new HyperLinkColumn();
oLink.DataNavigateUrlField = "IdField";
oLink.DataNavigateUrlFormatString = "~/Here{0}.aspx";
is dumping this to the page:
<a href="~/Here171201.aspx">
What changed between versions of IIS or .NET Framework could be causing this functionality to no longer work? The Tilde was definitely resolving in 1.1 - I have the exact same code deployed on a dozen 1.1 Framework servers in our organization. Unfortunately, the class that sets the DataNavigateUrlFormatString doesn't have access to the Page, so I'll have to do some kludging to insert the Page.ResolveUrl work around...
I'm not aware of anything changing, but I don't use HyperLinkColumns (I prefer the control which the Template column provides) so I've not looked for any changes .
One possibility as a proverbial band aid is to change this line:
oLink.DataNavigateUrlFormatString = "~/Here{0}.aspx";
to this:
oLink.DataNavigateUrlFormatString = Page.ResolveUrl("~/Here{0}.aspx");
If memory serves there was some issues when going to Master Pages and using the '~' from User Controls, but it's been a while since I read anything like that.
I don't think that the HyperlinkColumn of a Datagrid automatically resolves the URL into an absolute path. IIRC, the DataNavigateUrlFormatString property internally calls String.Format() only on the supplied format. Are you sure this worked correctly on .NET 1.1? IIRC, .NET 1.1 did not have tilde-based automatic URL resolution.
In my opinion, you should use the solution presented by Stephen (call Page.ResolveUrl manually.)
Related
Let's be clear, I don't really like WebForms. Which is why I do not wish to spend hours debugging a legacy code base that ran perfectly well on one server (IIS7) and a new one (IIS8).
I heard there is this new ClientIDMode, which makes forms and other controls change their IDs or not to something sensible, but I didn't touch it. It seems like the default value has changed (ie is not backwards compatible)?
I had a form in a master page that looked like <form id=SiteForm runat=server
This automatically changed its ID to aspnetForm in the rendered output.
Sure it was a bit weird, but I have a lot of code in this app that relies on it. I could simply change the ID in the server page to <form id=SiteForm runat=aspnetForm and that might fix it. But maybe there's some code in this old project that uses SiteForm on the server side, so I can search for that.
But there could be other controls lurking around which had their IDs changed too. So maybe there is something I can add to the web config to turn the behaviour back to what it was before? What was the default before?
UPDATE: Looks like when exporting and importing the app pools this site somehow got changed from .NET2 to .NET4, so perhaps I just need to set it back to .NET2?
I found that I had not ticked the box to install .NET 3.5 within IIS setup. This is why all my app pools reverted to .NET 4 automatically and why these weird changes happened. So I installed it in IIS, restarted, and set the app pool to .NET 2 (ie 3.5). This fixed it, cleanly, so I will call that the solution.
We have an existing CMS implementation, episerver 7.1, that has a .NET 4.0 app pool and is built against .NET 4.0.
This CMS is forms based and request authentication has been disabled for it. We have a custom page type that has an URL property, and we sometimes use a custom URI scheme in this URL property to dynamically look up catalog links in the code behind, mpc://16403 where 16403 us a unique ID for the product that is not market specific. [This allows the client to add the links once, and then the system looks up the correct market specific link]
We encountered an issue with a service on the machine and had to install .NET 4.5.
Suddenly we noticed that the custom links were being corrupted, changing mpc://16403 to mpc://0.0.64.19/
For some reason, after the installation of .NET 4.5, our custom URL is being converted to an IP address. None of the configuration has changed, only the installation of .NET 4.5.
Does anyone know why this is happening and how we can stop it from happening?
I would bet that under the covers, System.Uri is being used. If you look through the class reference, you will see that the class parses the string that is passed in to break it into its component parts (scheme, host, etc). In this case, it looks like the parsing logic was modified to assume that a hostname that consists of numbers is an IP address. As far as how to best handle this problem, it looks like you may want to either use strings (probably a bad idea) or a custom protocol handler.
OK, there seems to be a bug in how .NET 4.5 handles the System.Uri class.
Specifically it always applies IPAddress.Parse to the host, even if the scheme is unknown. This is wrong as not all 'hosts' are IP addresses.
The following code snippet produces mpc 00.00.64.19 in .NET 4.5 but in .NET 4.0 and .NET 4.5.1 it produces the correct mpc 16403
System.Uri myUri = new System.Uri("mpc://16403");
Console.WriteLine(myUri.Scheme + " " + myUri.Host);
So, if you want to use custom schemes with any class/feature derived from System.Uri do not use .NET 4.5 and go straight to .NET 4.5.1
I need to migrate my website which was earlier in target framework 3.5.
Now i need to convert it into 4.5, Please tell me that best approach to do it.....
I have tried with visual studio 2012 'Build' option to change it to 4.5.
But i am getting lots of script resource error mainly in js file, although these all works fine in 3.5.
After changing it to 4.5 , I m getting so many java script errors.
So, i am missing something.
Need to discuss these errors with you, so currently i am not including any error with you.
Please help me for the the right approach for this.
Any kind of help will be highly appreciated.
Thanks in advance.
You may have problems with some of the HTML elements you have marked as runat="server", specially iFrames.
So, if you a line of code (in you code-in-front) that looks like
<iframe id="myServerSideIframe" runat="server" src=""></iframe>
you are going to have problems loading them.
The reason is that the type of the corresponding variable in your code-behind for most of the HTML elements is "System.Web.UI.HtmlControls.HtmlGenericControl". However, in .Net 4.5, there are specific types for each HTML element, e.g. System.Web.UI.HtmlControls.HtmlIframe.
In order to resolve this, one easy way is changing the Id of that element in code-in-front, and changing it back to the original Id. That way, the designer will automatically update the variable declarations in the designer file.
Had converted web app from 3.5 to 4.0 (and then to 4.5)
When you open your app in VS2012, it will offer to migrate it to .NET 4.5.
Let it do the migration; most of the changes are in the web.config.
Refer to http://www.asp.net/whitepapers/aspnet4 and http://www.asp.net/vnext/overview/aspnet/whats-new for an overview of potential "breaking changes"
You may have javascript problems with ClientID; ClientIDMode=AutoID or static may help.
If you are using 3rd party .NET assemblies, some of them may not work properly.
You will have to check with the assembly author for new updates.
Good luck on the migration.
I am trying to create url routing like this
http://msdn.microsoft.com/en-us/magazine/dd347546.aspx
but I am having few questions , first why he is adding lines to the web.config , I tested it and it didnt appear that they're doing something as I commented them and nothing major appeared
second I am having this line of code that is crashing
var display = BuildManager.CreateInstanceFromVirtualPath(_virtualPath,typeof(Page)) as IProfileHandler;
when casted as ihttphandler it's working , but when I am casting it to iprofilehandler(which is implemeting ihttphandler) it's giving null !
This article is quite old as it's written before ASP.NET 4.0 was released.
Routing is now a core component of ASP.NET 4.
See this one instead:
http://weblogs.asp.net/scottgu/archive/2009/10/13/url-routing-with-asp-net-4-web-forms-vs-2010-and-net-4-0-series.aspx
These are really two questions here:
Why he is adding lines to the web.config - Web Configuration in .NET 4.0 applications has been greatly streamlined. A lot of the configuration that was done per-application is now included in the lower level web configuration (machine wide) (read). This means you don't need to add that configuration data in, its already done for you.
You're issue with BuildManager returning null. We'd need to see a little more code than that.
Hey I am coding using Visual Studio 2003. My program worked fine until I introduced a dll I made using CreateObject.
Code:
Set docs2 = server.CreateObject("DocGetter.Form1")
docs2.GetDocument oXMLDom,numID
It appears to be getting stuck at this code. I've already used regasm to register the dll.
What else could be wrong?
Add a reference to the dll in your project and instantiate the object like this:
Dim docs2 As New DocGetter.Form1()
If that doesn't make sense, then fix it so it does. There's no good reason to use CreateObject in .Net code. (Okay, that's hyperbole. But the principal is sound).
Can you clarify - is this a web app or a client (winform) app? Form1 sounds like a winform. ASP.NET runs at the server, so showing a form would be inappropriate - it would happen at the server, not the client. In short, don't do this!
I also can't see where "stored procedures" figures in this, so I've removed the tag.
What are you trying to do? Options for showing something more complex at the client include:
dhtml
flash
silverlight
clickonce [requires windows client]
ocx [not recommended]
I'd bet money that this function isn't defined with this name and/or parameters.
docs2.GetDocument oXMLDom,numID
But because of the way you're instantiating the object, the compiler has no way of knowing this... I think.