Downloaded code fails to compile

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi everyone,

This is probably a truly stupid question, but here goes.

I'm trying to use the VB version of an application framework. I'm sure it
works. I've been using the C# version for about 2 years.

The errors that I get when I compile are as if inheritance has stopped
working or as if I didn't have a valid reference to the System namespace.
For example a simple framework method that uses the "equals" method fails
because "'Equals' is not a member of Framework.BusObj"

The project references contain a reference to the System namespace, and
Imports System is set for the project.

One additional (probably significant) thing. When the framework projects
are being loaded into VS, I get a message that the .Net Runtime does not
fully trust the location of the code (it's only source at this point). Would
this stop the compiler from using Object.equals in my example above?
 
Continuing on...

I got rid of the "project location is not fully trusted" messages on load by
changing the code access security settings. I still don't know why I had to
do this as the download is only project source (no .exe's or .dll's).

At any rate I still have the errors I described in my original question.

Thanks for your help.
 
This is supposed to be a Managed Newsgroup. Having this conversation with
myself BITES!

The reason the downloaded code wasn't fully trusted is because of a change
that MS made to the way that Zipped Folders, and VS files in Zipped Folders
work. On NTFS filesystems, if you download Zipped Folders, the folder, and
code projects contained in the folder, are flagged as "untrusted". VS
notifies you that the code is untrusted when you attempt to load the projects
into VS. To get them to load "normally" you can right click on the zipped
folder, and choose the "unblock" button at the bottom of the first property
sheet.

I think this was a change that was made by a recent security "fix". Pretty
soon Windows / .Net will be so filled with kludged security crap that it
will take two days to figure out how to do anything.
 
Hi everyone,

My problem was caused by an omission in the documentation of the framework
code I was using. The framework was changed (a project was added to hold
globalized string resources), but the installation instructions failed to
mention that the new project assembly.info contained a strongname key value
that had to be updated to one accessible from VS.

Once updated to my strongname key, the dll compiled properly.

What I don't understand is how this could have possibly caused the behavior
I saw. But it did.

Another stimulating conversation with myself.
 
Back
Top