Scott Hanselman

Moving the Code-Behind Assemblies/DLLs to a different folder than /BIN with ASP.NET 1.1

October 27, '04 Comments [3] Posted in ASP.NET | Web Services | XML | Bugs
Sponsored By

Apparently there's a number of places online that say this can't be done. We needed to be able to add pages to an existing application that were basically "sub-applications," and they'd have their own /bin folder, but still be in the same VDIR and participate in the same IIS Application.

So instead of:

/webapp
 default.aspx
 foo1.aspx
     /bin
      app.dll
      foo1.dll

We could have

/webapp
 default.aspx
     /bin
     /mysubapp
      foo1.aspx
          /bin
           foo1.dll

If you try this directory layout as is, you'll get a "Parser Error" as ASP.NET freaks out due to its inability to find the code-behind for foo1.aspx.

However, if you add a private probingPath to your web.config:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="mysubapp/bin" />
    </assemblyBinding>
  </runtime>
<configuration>

And, tell your ASPX page where it can find it's code-behind file BEFORE the System needs it for the Inherits= attribute in the @Page directive:

<%@ Assembly Name="Foo1" %>
<%@ Import Namespace="FooNamespace" %>
<%@ Page language="c#" Trace="true" Codebehind="Foo1.aspx.cs" AutoEventWireup="false" Inherits="FooNamespace.FooWebForm1" Debug="true"%>

You'll be all set. Slick. Of course, this is all ASP.NET 1.1, and everything changes with 2.0 and the "/Code" directory, but it's still slick IMHO, and allows for a level of flexibility that I haven't seen before.  It also keeps your man/bin nice and tidy if you've got folks "plugging in" other pages to your web app.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Giving a Mapped Network Drive "FullTrust" with .NET Code Access Security

October 27, '04 Comments [0] Posted in Programming | Tools
Sponsored By

I'm saving this so I can find it easily later. Chris Sells has a post that describes how to give a Mapped Network Drive "FullTrust." Thanks Chris!

[When loading a Project from a Network Drive (like Z:\, perhaps within a VPC) you may receive:]

The project location is not trusted.
Running the application may result in security exceptions when it
attempts to perform actions which require full trust.

What's happening is that VS is detecting that the project on the network drive is getting Intranet permissions according to the good and true workings of .NET Code Access Security (CAS). However, since I'm just trying to pretend that Z is on my PC (and, in fact, it is), I want it to have FullTrust permissions.

To accomplish this, you need to add a new Code Group with an URL membership permission specifying the folder (in URL form) to which you'd like to grant full trust. You can do with the .NET Framework Configuration tool or you can do it from the command line like so:

c:\>caspol -q -machine -addgroup 1 -url file://z:/* FullTrust -name "Z Drive"

Once this new code group is in place, any new .NET processes you start will give any assemblies on the Z drive full trust.

Since awarding new permissions, full trust or not, to any chunk of code is something that can cause a security hole, be careful.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

MSDN Product Feedback for Whidbey: The /fs "Font Size" switch has been REMOVED.

October 27, '04 Comments [1] Posted in ASP.NET | Bugs
Sponsored By

Folks, help me out by voting for this obvious accessibility issue in VS.NET 2005 (Whidbey) Beta 1:

Description:
Opened by Scott Hanselman on 2004-10-26 at 23:21:05
   
The /fs "Font Size" switch has been REMOVED from the DevEnv.exe command line in Whidbey.

This is an accessibility issue that prevents folks who are visually impaired from launching DevEnv.exe with different font sizes for different purposes.

Additionally it represents a REMOVAL of functionality that has been present in the previous two versions of VS.NET.

 

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Mixing Metaphors and Making Things Too Complex (REST and SOAP)

October 26, '04 Comments [5] Posted in Web Services
Sponsored By

Folks keep trying to push metaphors (or similes, like, depending on how you say it) a smidge too far. Steve Maine had some words for Mark Baker. That said:

Patrick and I sat down to talk about this:

  • REST:
    • I write a letter, a document even, and it has no address on it and doesn't even say "Dear Patrick."
    • I tell the Postman, remembering that I'm only able to tell him two things, GET and POST, to take this letter to my friend Patrick.
      • POST /patrick.aspx HTTP/1.0
    • If the Postman puts the document (not a message, considering that he's the only one who knows where it's going) down on the seat, in order to Store and Foward this message - is it a letter? No, it's a document with no destination.
    • REST doesn't cover this. The address is out of band.  It's not on the "envelope" as there IS NO ENVELOPE.  Trying to say that the HTTP Headers are a Poor Man's Envelope succeed only in describing a very poor man.
  • SOAP
    • I write a letter, a document even, and it has no address on it and doesn't even say "Dear Patrick."
    • I put it in an envelope (also, a folded piece of paper, except this one has glue on it in certain places and a licky part) and put ATTN: Patrick (WS-Addressing) on the outside with some wax seals (WS-Security) and a Notary Public Stamp (WS-Trust).
    • If the Postman puts the document on his seat, the document (now a bona fide message) could be delivered by a substitute Postman.
    • Thus, SOAP adds, gasp, value by simply formalizing addressing, containment, and with WS*.*, security and trust.
    • And, it's transport independent. The Postman is free to use a Mule or a Segway.

How anyone can argue about this is beyond Patrick and I.

REST is interesting, and when simplicity is called for, knock yourself out.  But seriously, I can see why some may call them RESTafarians because more often than not "Hay now, Mista Postman, tak dis letta to mwa bwoy Patrix. Eim dwon undastan SOAP." doesn't cut it if you really want your letter to arrive.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Why don't developers switch/migrate/convert from VB6 to VB.NET?

October 26, '04 Comments [12] Posted in Programming
Sponsored By

IMHO, it’s because converting (both projects and your mind) to VB6 to .NET is hard.

  • VB6 existed for one reason and one reason only – to hide the complexities of COM.
    • VB6 was the Matrix, while VB.NET is as powerful as C#. Some folks say, well, while I'm here, I'll just move over to a language with "C" in it, and maybe I'll get more money?
  • VB.NET aims to hide nothing – and the exposure is scary to many.
    • VB.NET looks like VB7 - but it's not.
  • VB6 solved the problem of multithreaded Windows Forms by not allowing it. 
    • VB.NET’s WinForms and the BeginInvoke, AsyncResult, and InvokeRequired of it all is complex for anyone, especially a VB6 Mort.
  • VB6 is used by places like "Podunk County School District" and "Whatever, Kansas Dept. of Forestry."  These are places where Microsoft Access is fine, therefore VB6 is "fine."
    • Until Microsoft explains why VB6 isn’t "just fine" – folks will linger.
  • The Migration Path is not clear and VERY complex – if you did anything funky with OCXs, or if a component vendor didn’t provide you with a migration path, you’re screwed. 
    • The Migration Wizard is an amazing chunk of work, but the 20% edge cases are hard.
  • Making no decision at all is an implicit decision.  Many VB6 developers are paralyzed. That is a decision not to move forward.
    • Safety first, and safety in numbers.

What do you think? Do you have buddies that are still on VB6? What are they doing it about it? Is VB6SP5 "just fine"? Is VB6 a technology that Microsoft should continue to support?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.