Serve extensionless URL without using ISAPI handler or wildcard mapping

http://www.codeproject.com/KB/aspnet/extensionless.aspx

The out parameter 'xxx' must be assigned to before control leaves

void myVoid (out string xxx)
{
if (...)
{
xxx = ....
return;
}

xxx = ""; // bu kısım olmadığında başlıktaki hata oluşuyor.
}

http://bytes.com/topic/net/answers/116772-url-rewriting-problems-postbacks

connectionstring by using web.config

< asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString=' < % $ ConnectionStrings:Main.ConnectionString % > '
SelectCommand="Select CategoryID, Title, UpperCategoryID From Category" / >

web.config:
< connectionStrings >
< add name="Main.ConnectionString" providerName="System.Data.SqlClient" connectionString="data source=pisipisi\sql2008; initial catalog=yapimatik; Trusted_Connection=yes" / >
< / connectionStrings>

The changes you have made require the following tables to be dropped and re-created

When changing tables in SQL Server Management Studio 2008 you may get the following error: Saving changes is not permitted. The changes you have made require the following tables to be dropped and re-created. I was surprised when I saw this message first but there is very simple solution.

From top menu select Tools and then Options. Select Designer and Table and Database Designers.

Uncheck the box Prevent saving changes that require table re-creation. Now you can edit your tables without being stopped by re-creation limits.

Update. As mxmissile pointed out in his comment then don't use this on tables with millions of rows.

http://weblogs.asp.net/gunnarpeipman/archive/2009/04/08/the-changes-you-have-made-require-the-following-tables-to-be-dropped-and-re-created.aspx

Url Rewriting Breaks ASP.NET 2.0 Themes - HttpContext.ReWritePath - Screws Up Link to StyleSheet

I was neck deep into ASP.NET 2.0 Themes and Url Rewriting today when I came across the fact that Url Rewriting breaks your ASP.NET 2.0 Themes by changing the base file path looked at by the client and screwing up the relative URL to your stylesheets. Actually, I expected this to happen, but I didn't think the fix was going to be so simple.

Much thanks goes to Fabrice who I remembered blogged about this problem with Url Rewriting and ASP.NET 2.0 Themes the other day.

Turns out this problem with Url Rewriting and ASP.NET 2.0 Themes was reported to Microsoft and they created a new boolean parameter for HttpContext.RewritePath, called rebaseClientPath, that allows you to specify whether or not you want the virtual path reset when doing Url Rewriting.

public void RewritePath (string path, bool rebaseClientPath)

By default, rebaseClientPath is set to true, which is why the links to the stylesheets are broken. If you are doing Url Rewriting with ASP.NET 2.0 Themes and having problems with your stylesheets, change your code to set rebaseClientPath to false and it may fix your problem.

http://davidhayden.com/blog/dave/archive/2006/01/14/2693.aspx

Don’t run production ASP.NET Applications with debug=”true” enabled

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the switch on within the application’s web.config file.

Doing so causes a number of non-optimal things to happen including:

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached

This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser. This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources. Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

When is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers). If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

What about binaries compiled with debug symbols?

One scenario that several people find very useful is to compile/pre-compile an application or associated class libraries with debug symbols so that more detailed stack trace and line error messages can be retrieved from it when errors occur.

The good news is that you can do this without having the have the switch enabled in production. Specifically, you can use either a web deployment project or a web application project to pre-compile the code for your site with debug symbols, and then change the switch to false right before you deploy the application on the server.

The debug symbols and metadata in the compiled assemblies will increase the memory footprint of the application, but this can sometimes be an ok trade-off for more detailed error messages.

The Switch in Maching.config

If you are a server administrator and want to ensure that no one accidentally deploys an ASP.NET application in production with the switch enabled within the application’s web.config file, one trick you can use with ASP.NET V2.0 is to take advantage of the section within your machine.config file.

Specifically, by setting this within your machine.config file:







You will disable the switch, disable the ability to output trace output in a page, and turn off the ability to show detailed error messages remotely. Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).

Setting this switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leakages. There isn’t a ton of documentation on this switch – but you can learn a little more about it here.

Hope this helps,

Scott

Updated: Tess has a great follow-up post with more details about what happens when debug="true" is enabled. You can read it here.

http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx

httpmodule in iis 7 & windows server 2008

eğer bir httpmodule (bir dll veya app_code dizinindeki bir class) iis 7 & windows server 2008 üzerinde çalışmıyorsa (ve herhangi bir hata vermiyorsa), bu modülü global.asax dosyasına yerleştirmek sorunu çözüyor. örnek:

httpmodule:

namespace xxx.Authenticator
{
public class Authenticator : IHttpModule
{
#region IHttpModule Members

public void Dispose() { }

public void Init(HttpApplication context)
{
context.AcquireRequestState += new EventHandler(context_AcquireRequestState);
}

#endregion

private void context_AcquireRequestState(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
HttpContext context = app.Context;
//IHttpHandler handler = app.Context.Handler;

string extension = VirtualPathUtility.GetExtension(app.Context.Request.Path).ToLower(Common.Common.CultureEN);

if (extension == ".aspx")
{
string path = app.Context.Request.AppRelativeCurrentExecutionFilePath.ToLower(Common.Common.CultureEN);
Utility.RedirectUrl = path;

if (!string.IsNullOrEmpty(app.Context.Request.QueryString.ToString()))
Utility.RedirectUrl += "?" + app.Context.Request.QueryString;

User currentUser = Utility.CurrentUser;

const string loginUrl = "~/admin/login.aspx";

if (!path.Contains(loginUrl)) // exception
{
// check user
if (path.Contains("/admin/"))
{
if (currentUser == null || currentUser.IsAdmin != true)
{
context.Response.Redirect(loginUrl + "?rUrl=" + Utility.RedirectUrl.ToLower(Common.Common.CultureEN));
}
}
}
}
}
}
}

global.asax:

void Application_AcquireRequestState(object sender, EventArgs e)
{
...
}

HTTP Error 500.19 - Internal Server Error

HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.")

applicationHost.config dosyasını açın (%windir%\system32\inetsrv\config\applicationHost.config)

section name="handlers" overridemodedefault="Deny"

satırında "Deny" yerine "Allow" yazın.

http://blog.donnfelker.com/2007/03/26/IIS7ThisConfigurationSectionCannotBeUsedAtThisPath.aspx

single select asp.net treeview

< asp:TreeView ID="TreeView1" runat="server">

script type="text/javascript" >
function client_OnTreeNodeChecked(event, tree) {
var TreeNode = event.srcElement || event.target;
if (TreeNode.tagName == "INPUT" && TreeNode.type == "checkbox") {
if (TreeNode.checked) {
uncheckOthers(TreeNode.id, tree);
}
}
}

function uncheckOthers(id, tree) {
var elements = document.getDocumentById(tree).getElementsByTagName('input');
// loop through all input elements in form
for (var i = 0; i < elements.length; i++) {
if (elements.item(i).type == "checkbox") {
if (elements.item(i).id != id) {
elements.item(i).checked = false;
}
}
}
}
}
script

private void Page_PreRender(object sender, EventArgs e)
{
TreeView1.Attributes.Add("OnClick", "client_OnTreeNodeChecked(event, '" + TreeView1.ClientID + "')");
}

onLoad Timed Redirect

http://www.webmasterworld.com/forum91/2103.htm