I would like to know the answer to this one too. I know it has to do with the
Code Access Security, but I am not sure what exactly. I don't know if has
anything to do with developing on a machine that is not the SharePoint Server.
The temporary solution seems to be to put the Web Part assembly in the GAC.

I feel your pain.

1. VS auto increments the version number by default. verify that
the version number you entered in your dwp file is the same as the
dll.
2. are you using a resource that WSS_Minimal doesn't give rights to
by default. Opening files on server or calling web  service? You'll
need to edit the WSS_Minimal.config file.
3. Are there multiple entries in the web.config file for your
webpart. This happened to me as a result of VS auto incrementing
the version number.
4. Have you entered the publickeytoken attribute into you dwp file
for your webpart?

resources i found helpful:
www.msdn.microsoft.com/.../...eployingwebparts.asp" target="_blank" rel="nofollow">www.msdn.microsoft.com/.../...eployingwebparts.asp

www.msdn.microsoft.com/.../...eployingwebparts.asp" target="_blank" rel="nofollow">www.msdn.microsoft.com/.../...eployingwebparts.asp

1. I have hard coded the version number in the assembly file so this
shouldn't be the issue, the dll always compiles to version 1.0.0.0, this
is what I have in the .dwp file and in the web.config file.

2. Haven't heard of WSS_Minimal, will do some more investigation on
that.

3. There were multiple entries in the web.config file from trying to
use the cab install method, but I have manually removed these and then
restarted IIS.

4. Now this is where I have a feeling the problem could be. Does
anyone know if I have to strong name on the machine the dll will
essentially be running on? Or is it okay strong naming it on my machine,
making sure all the tokens match and then copying it onto my web  server?

I was able to strong name my dll on my development machine and install it on my portal server. The WSS_MinimalTrust.config file is installed in the following directory on the portal server: “C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\CONFIG”. This will only be relevant however, if the trust level for your portal is set to “WSS_Minimal” in the web.config of your portal site.

You’re probably doing this already, but I’ll suggest it anyway. Try making a “Hello world” web  part first. This will eliminate dependencies on rights not given by default and also not require a strong name. Along those lines you might try eliminating the strong name for the moment. That way you can remove the PublicKeyToken attribute from the SafeControls entry and not need to worry about the WSS_MinimalTrust.config file.

Make sure that the dll is in the bin folder of your portal site and your remaining issues should boil down to the web.config file and the SafeControls entry of your webpart dll.

You can try turning the CAS check off to see if this is indeed the problem.
One way of doing that would be caspol -security off from command line.

Also, you may find the following article that talks about CAS and SPS
helpful.
msdn.microsoft.com/.../...sscodeaccesssecurity.asp

Okay... for those that were interested, have sorted this at last.

It would appear it was a problem of my own making... (awaiting the collective groan) basically the *server* I have Sharepoint installed on has 2 drives available, C with 6Gb and E with 36GB. In my wisdom I had decided to try to use E:\inetpub\wwwroot as the 'home directory' for the Default Web Site by changing it in the properties of IIS. Almost as a last resort I changed this back to C: and after a reboot of the server things started working.

As an extra point, my journey through trying to resolve this has revealed an interesting tip. For those that are trying to glean the public key token for your dll using the "sn" utility. Don't use -t as it states in much of the documentation as this gives the wrong token, use -T.

Thanks to those that took time to reply to my original cry for help.

The situation I had was that I had a portal already setup with a fairly minimal spec server running SQL for the back end and a seriously under-specced PC running web  etc.

The machine I have now became available so I decided to set that up and add it to the existing setup as a second web server before removing / decommissioning the PC. This would have meant that IIS and the default web site were initially situated on C: when the portal was added to that server.

To actually move the site to the E drive, I used a fairly caveman approach. I copied the inetpub directory to the E drive, went into IIS Manager on the server, selected the properties of the default web site and changed the home directory to the new location of e:\inetpub\... I then renamed inetpub on the C drive to something like oldinetpub to ensure it wasn't being used / needed.

I hope this provides a bit more background, let me know if there is anything else you need to know.

I too elected not to use the C:\ drive for any of my sharepoint  work so we created a site on the e:\ drive but I have not been able to use VS.NET to connect to that site. Anyone with similar experiences? Why would the product expect you to work against the C: drive after all in most environments you'd never do that for security reasons a Server admin would lock down the C (or system ) drive and share out folderss on a different partition.

Whay do ASP hosters allow for Sharepoint authoring using VS.NET. Of teh 4 hosting firm I am aware of non of their FAQs or Support pages mentions VS.NET at all some allow FP2K3 but then you basically can't do anything but tweaking ASPX since you can't have script on pages in WSS.

I have been able to create a site on a drive other than C and install a custom web  part in that site. I’m unclear on what you mean by using VS.Net to connect to the site. In my case, I am using an XP workstation to write the web part in VS.Net and creating  a cab file for installation. I am sorry if I’m adding to the confusion, but I’m a bit puzzled myself. Simon, can you give more details about how you established a portal site your e drive?

There is a whole area on "developer environment" that is poorly - if at all - documented. For example where in MS public documentation is STSFLTR.DLL documented? So far only PatrickT at www.u2u.net seems to have written about it. I think there are a few MS slides from the April AirLift that also mentions it.

My gut feeling is that for this version of WSS MS expects you to have near Admin privs to a WSS server. Since they are in the architect/developing phase for version 3.0 and since the Web Parts are going into ASP.NET 2.0 hopefully the development requirements will become more delegated so you could create a 'developer role' rather than granting Admin role.

For example I'd like to put a ASP.NET page in/on my Sharepoint site that accesses the Object Model- I am sure it can be done but there seems to be a few issues associated with this or at least some steps you need to follow. The SDK has a few pages on it but again it looks to me like I need to access the layouts folder on the C: drive and the way we have set up our servers only Admins have access to that path.. is there a best practice that says its ok to share that out? What about if you have multiple teams developing..are they all using the same folder ? or can you create a project folder below that and then ACL it only to those specific developers?

Debugging is another area that looks like you need admin privs.. back in May 2003 an article appeared on MSDN written by Suraj Poozhiyil of MS it is pretty specific .
And in our shared environment we are not allowed to attach to the w3wp process because the first guy who does effectively blocks the others-apparently that changes in ASP.NET 2.0/IIS7/.NET 2.0 timeframe as per Robert Howard and Scott Gus comments at PDC...