Vincent Van Den Berghe

Determining the Set of Permissions and Creating the Permission Set At this point, we should think about the permissions our component needs. We're creating our own code group and permission set, so we start from scratch: this means that we'll have no permissions at all to start with. So, in addition to the permission to call unmanaged code (which we need to solve the event-handling problem that got us into this mess), we also need to include the permission for our assembly to execute. If we forget to include "execute permission," our component will simply refuse to load. But wait, there's more: when Internet Explorer creates the AppDomain to load our assembly, it first determines the set of permissions that can be granted to it. That set of permissions is based on "evidence." Internet Explorer uses three evidence classes: Site: the Web site the assembly is coming from Z... (more)

.NET Feature — Writing Client Components in .NET

To solve problems DHTML, JavaScript and XML can't handle, you sometimes need so-called "rich" client components for your Web applications. Traditionally, this is the realm of Java (applets) or ActiveX controls. If your clients are using Internet Explorer 5.5 or higher you have another choice: write your client components in .NET and host them in Internet Explorer. This is an interesting and viable choice if the rest of your development work is also in .NET, since you can use a single technology and a single framework for all your needs, both on the client and the server. This is... (more)