Problem ~ Error while tryping to run project: Unable to start debugging on the web server. You do not have permission to debug the application. The URL for this project is in the Internet zone. Click Help for more information.

I was getting this error recently when I was trying to debug ASP.NET 2.0 web project with Microsoft Visual Studio 2005 Professional Editor. Initially, I have no problem in debugging the web project in my machine. I think that the System Team made some security policies changes in my office. I did some experiments on this issue for some time and I found the following steps to solve this problem. Honestly, I’m not so sure which steps is the actual solution but I’m sure that this problem will be solved if you follow this step.

Solution ~

Step 1: Ensure that you account and ASPNET account is listed in Debugger Users group.

Step 2: ASPNET account has the permission to read (or write) your web directory.

Step 3: Add “localhost” or “*.local” in “Exception” panel of Proxy Setting. ( Internet Explorer>Internet Options>Tools>Connections>LAN Setting>Advanced button of Proxy Server>Exceptions>”Do not use proxy server for addresses beginning with ~”)

Step 4: Add http://localhost to the trusted site.

Step 5. Run “iisrest” in Command Prompt

Then, it should work. If it doesn’t work, add ASPNET User account to Administrators Group. And try it again. I hope it will work for you. Feel free to let me know this solution doesn’t work for you or you know the better solution. Thanks.

———–

Problem ~ Visual Studio .NET has detected that the specified Web server is not running ASP.NET version 1.1. You will be unable to run ASP.NET Web applications and services.

Solution ~

#1. Check the property of your web application. Most probably, your application is using ASP.NET 2.0 version instead of 1.1. So, you can simply change it to ASP.NET version 1.1.

#2. If it doesn’t work, run “aspnet_regiis” in command prompt.

Hope it will work for you too.

—————

Question ~ Why doesn’t C# support multiple inheritance?

Answer ~

The following is answered by Microsoft C# Team. The original post can be found here. I posted the copy here in case the original one disappears and I like this answer so much. ( Honestly, it’s kinda hard to understand. :) )

There are a number of reasons we don’t implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance).

However, I should point out that it’s possible for compilers to create MI for their types inside the CLR. There are a few rough edges if you go down this path: the result is unverifiable, there is no interop with other languages via the CLS, and in V1 and V1.1 you may run into deadlocks with the OS loader lock. (We’re fixing that last problem, but the first two problems remain). The technique is to generate some VTables in RVA-based static fields. In order to deposit the addresses of managed methods (which probably haven’t been JITted yet), you use the VTFixup construct. This construct is a table of triplets. The triplets consist of a token to a managed method, an address in your image that should be fixed up (in this case, a slot of the VTable you are creating in the RVA-based static), and some flags. The possible flags are described in corhdr.h and they allow you to specify 32- vs. 64-bit pointer sizes, control over virtual behavior, and whether some reverse-PInvoke behavior should be applied in the form of a thunk that eventually dispatches to the managed method. If we are performing an unmanaged->managed transition, you also have some control over which AppDomain should be selected for us to dispatch the call. However, one of these options (COR_VTABLE_FROM_UNMANAGED_RETAIN_APPDOMAIN) doesn’t exist in V1. We added it in V1.1.

There are several reasons we haven’t provided a baked-in, verifiable, CLS-compliant version of multiple implementation inheritance:

1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don’t want this concept (presumably VB.NET, for example). Of course, that’s the business we are in as a common language runtime, but we haven’t got around to doing it for MI yet.

2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?

3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

It’s not at all clear that this feature would pay for itself. It’s something we are often asked about. It’s something we haven’t done due diligence on. But my gut tells me that, after we’ve done a deep examination, we’ll still decide to leave the feature unimplemented.

————-

I found this question and answer below in codeproject forum that I used to participate. I think it’s very interesting.

Question : True and False – Best Practices

A few colleagues of mine are in disagreement as to what is the best practice for coding boolean flags. Should you use the actual words “true” or “false” or use the integers “1″ or “0″ (or -1 in some languages) respectively.

I favor a boolean flag to show values as “true” or “false” because it makes reading 800 lines of code easier. 0′s and 1′s can be confusing, in my scenario, because we are constantly setting variables back to a regular integer values of 1 or 0.

Thanks!

Answers ~

I believe you are right. In terms of readability if the language you are using actually supports the boolean type and the true,false keywords then it means is recommended to use them. In certain cases this will not be true. For example C did not have a book type until C99 came out and then C++ provided bool type and true/false keywords as a built in feature. If you do use C++ then it is recommended to use the true/false type since they are provided. Even in C , it was a good coding practice to #define the keywords TRUE and FALSE to 1 and 0 respectively to provide a more readable code.
Just my humble opinion

I agreed with this answer for this question. Why you wanna use 0 and 1 while Microsoft is providing the boolean type for us? :)

Related ~

• Some interesting ASP.NET 2.0 FAQ
• Some FAQ from ASP.NET web development
• [Tips/Tricks] ASP.NET with SQL Reporting Services
• Tips/Tricks – How to control MaxLength of Multiline TextBox in ASP.NET 1.1?
• How to get the user information from Active Directory in ASP.NET