Setting Up Computer to run IIS/ASP.NETwith C# - C# Discussion Boards

Jinwah16-Dec-03 4:27

16-Dec-03 4:27

Can anyone help?

I want to code an interface and assign a GUID to it.

public interface IMyInterface
{
}

On the web I found articles that say I should put the interfaces GUID above the interface declaration. But I get an error message saying GUID is not recognised. My using clause has System. So how can I do this?

The reason is in Delphi my objects support interfaces and then by zooming thru a list of objects I can ask if the object supports the interface and if so talk to the object thru that interface.

I have had a good look thru my books and internet articles but cannot find any really good info.

If there is a new way to do this I would also be interested.

Thanks

Luke

Re: interfaces and GUIDS

Heath Stewart16-Dec-03 5:11

Heath Stewart

16-Dec-03 5:11

Yes, you do use the GuidAttribute but you must use the right namespace: System.Runtime.InteropServices. You can either include it toward the top with the using statement, or prefix your GuidAttribute (or any class for that matter) with the proper namespace. You must also be referencing the assembly in which the Type contains. I'm only mentioning this so you understand. The System.Runtime.InteropServices.GuidAttribute Type is in the mscorlib.dll assembly, so it is automatically referenced by the compiler (unless it's told otherwise, which is only possible with the command-line compiler).

-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

Re: interfaces and GUIDS

Jinwah16-Dec-03 5:34

Jinwah

16-Dec-03 5:34

is that above the interface declaration

System.Runtime.InteropServices.GuidAttribute["....."]
public interface IMyinterface
{
}

And how can I ask an object if it supports the interface so that I can talk to it soley thru that interface (this is how I would have done it in Delphi)

Cheers

Luke

Re: interfaces and GUIDS

Heath Stewart16-Dec-03 5:45

Heath Stewart

16-Dec-03 5:45

No offense meant, but you should probably read the C# specification. Attributes are like so (fully-qualified example):

[System.Runtime.InteropServices.Guid("363EBCCC-5E9A-4e14-8A5D-F0DA44E69EF9")]
public interface IMyInterface
{
{

In C# (and some other languages, but you have to read their specs to find out), you can drop the "Attribute" at the end of attributes. If you want to use properties that aren't in the constructor parameters, fill all the necessary params then use PropertyName=Value, like so:

[MadeUpAttribute("somestring", SomeParam="SomeValue")]
public class SomeClass
{
}

Re: interfaces and GUIDS

Jinwah16-Dec-03 22:04

Jinwah

16-Dec-03 22:04

No offence taken. I have brought 2 very good reference texts for C# / .NET. My problem is that I professionally program in Delphi. So I know what I want to do but I haven't yet got used to framing the question I want to ask in C# terms to get the answer. But moving to C# has been very easy due to the similar class libraries so I have a head start on my fellow C++ m8s.

Thanks for your help tho.

Re: interfaces and GUIDS

Heath Stewart17-Dec-03 3:13

Heath Stewart

17-Dec-03 3:13

My comment wasn't in reference to how you "framed" your question, but rather your syntax. Attributes in C# are enclused in square brackets ([ and ]) and you tried using them for your constructor params, which are always parens (( and )). This is just a simple matter of syntax. While it's true that the syntax (i.e., language) you use to write your code for .NET isn't really so important (knowing how to use and extend the base class library, and how to make your own libraries and applications is more important), you still need to know the syntax of the language you've choosen. I was just pointing out that you should read over the C# language specifications to know exactly what the syntax is - you might even learn a few tricks that aren't always discussed in books (like using the using statement to automatically dispose IDisposable implementations, or to use the same statement to creat a Type alias (especially handy when you have Type collisions, i.e. two different Types with the same name that belong to two or more namespaces you've imported).

Re: interfaces and GUIDS

Member 26118817-Dec-03 6:02

Member 261188

17-Dec-03 6:02

Im my opinion, a good example of the uses of attributes is when it comes to describing properties for the property explorer in Visual Studio.net.

using System;
using System.ComponentModel;

namespace Examples
{
    public class ExampleControl : UserControl
    {
        private IndentStyle m_eExampleProperty = IndentStyle.Smart;
        [
        Category("Design"),
        Description("Gets/sets an example value."),
        DefaultValue(IndentStyle.Smart),
        Browsable(true)
        ]
        public IndentStyle ExampleProperty
        {
            get
            {
                return m_eExampleProperty;
            }
            set
            {
                m_eExampleProperty = value;
            }
        }
    }
}

This would produce this kind of output:

If you want to try this out, just cut-and-paste the code into a source file, and create an instance of the control on the designer form.

- Daniël Pelsmaeker

Microsoft is to quality software what McDonalds is to gourmet cooking

Setting Up Computer to run IIS/ASP.NETwith C#

Larry J. Siddens16-Dec-03 4:22

Larry J. Siddens

16-Dec-03 4:22

I need some help getting my puter setup to run ASP.NET apps. I have IIS installed and the Web Publishing is running. I have also shared the folder where the app is. I keep getting an error:

"http://localhost/<name> HTTP 500 internal error!

Real informative! Can anyone give me some suggestions on what needs to be running?

Thanks

Larry J. Siddens

Re: Setting Up Computer to run IIS/ASP.NETwith C#

Heath Stewart16-Dec-03 5:08

Heath Stewart

16-Dec-03 5:08

Well, for one, you need to install ASP.NET with the .NET Framework. If you're having problems, you should run "aspnet_regiis.exe /i". Read more about aspnet_regiis.exe in the .NET Framework SDK documentation. There's some other options.

Another possibility is that your ASP.NET page - or your IIS extension mappings - have an error and are causing a server error. Without knowing more, it's hard to say. The error says it all: server error. Millions of things could be wrong.

Re: Setting Up Computer to run IIS/ASP.NETwith C#

Larry J. Siddens16-Dec-03 7:03

Larry J. Siddens

16-Dec-03 7:03

Hey, new message!

Unable to open Web project "project name". The file path <path> does not correspond to URL 'http://Localhost:/<project name>'. the two need to map to the same server location. HTTP Error 403: Access.

I get this when I open a project under C#!

Larry J. Siddens

Re: Setting Up Computer to run IIS/ASP.NETwith C#

Heath Stewart16-Dec-03 11:06

Heath Stewart

16-Dec-03 11:06

HTTP error code 403 is access denied. Check your filesystem permissions and make sure that the account under which ASP.NET runs (by default, a local user named ASPNET) has permissions to at least read and list the files and directories. Also make sure that your account has read/write permissions.

Second, you must already have a project in the web application (in this case, the root application on 'localhost'). If you do, you might try typing the name in, like 'http://localhost/project.csproj'. Sometimes VS.NET doesn't show directories correctly, but I've really only experience this with remote servers on a different network (like opening up a project at work from home).

Finally, the project in 'http://localhost' has to have that host in the project file itself. The project file is just an XML file so browse to the directory in which your project is located (for example, 'C:\Inetpub\wwwroot'), open it up in notepad or some other vanilla text editor, and change the host to match the location in which you're trying to open it.

Re: Setting Up Computer to run IIS/ASP.NETwith C#

Not Active17-Dec-03 3:22

Not Active

17-Dec-03 3:22

I've run into this several times before. The most likely this what you need to do.

http://www.codeproject.com/script/comments/forums.asp?forumid=12076#xx693463xx[^]

problem with a shared assembly in a VS solution

Tim Kohler16-Dec-03 3:19

Tim Kohler

16-Dec-03 3:19

I'm having a problem with shared assemblies > 2^16 bytes in size.

My assembly is in a solution along with a console app that references the
assembly. The app is set up to reference the assembly (the reference path
is pointed to the assemblies output directory). When I do a build, the
assembly is failing to build because the .dll is loaded. If I remove the console app's
reference to the assembly everything is fine.

I'm getting the following output from the build:
The file 'Test_Library.dll' cannot be copied to the run directory. The
process cannot access the file because it is being used by another process.

Could not copy temporary files to the output directory.

I've created a few other shared assemblies with no problems. This is the
first time I've seen this exact problem and in trying to run it down I've
discovered that if the .dll's size is < 65536 bytes (as all my other ones
are), this doesn't happen. It looks like VS is loading the .dll when I add
the reference for the console app. If I delete the console app's reference
to the assembly, I am able to build the library.

I hope one of you has run across this before.

thanks for any help

Re: problem with a shared assembly in a VS solution

Heath Stewart16-Dec-03 3:45

Heath Stewart

16-Dec-03 3:45

Yes, and it's definitely a bug in VS.NET. One thing that helps eliminate the problem is to use a Project reference instead of a file reference. When adding the reference to a project in your solution to another project, click on the Projects tab in your Add Reference dialog. Select the project. This not only helps eliminate the problem a little, but it also ensures that whenever you make a build of your library/application, that the proper build of the dependency is created as well. For instance, when you create a Debug build all dependencies are built in debug mode.

When this problem occurs, pretty much all you can do is make sure that your application isn't running (use the Process tab in the Task Manager to really make sure - just because you can't see it doesn't mean it's not running) and restart VS.NET to get it to release the lock on the executable(s).

Re: problem with a shared assembly in a VS solution

Tim Kohler16-Dec-03 4:04

Tim Kohler

16-Dec-03 4:04

Alright, thanks for the feedback. I'll try a project reference. This is a real bummer though.. <sigh>

I hope they fix this soon as it really stinks up developing a library of any size.

Re: problem with a shared assembly in a VS solution

Heath Stewart16-Dec-03 4:07

Heath Stewart

16-Dec-03 4:07

It doesn't have anything to do with the size of the assembly. You've found a pattern, but a pattern unique to you. That happens to us with assemblies of all sizes, and assemblies that are referenced by others both frequently and infrequently.

This problem exists in both VS.NET 2002 and 2003. While I too hope they fix it, it's not looking too good. I know a lot of people - including myself - have posted this bug to their newsgroups, but you should as well (use the NNTP server msnews.microsoft.com or the web-based news reader on their site in various places). Every mention should help.

Drag Drop - Simple Theory - Simple Solution?

Tristan Rhodes16-Dec-03 2:58

Tristan Rhodes

16-Dec-03 2:58

Would it be possible to combine the FileFormat.FileDrop with an automatic file construction?

For instance, when the mouse button is pressed, and dragdrop is intiated, when the mouse pointer leaves the managed enviroment, the program constructs the dragged item in the root / temp directory, and forwards the file name (With path) to the arguments used by the dragdrop, thereby, the file is created in the temp directory, and then moved.

This would negate the need to worry about interfacing with COM, and simplify the whole process.
The only things I am uncertain about are:

1) How to determine when the mouse has left the managed enviroment. (X,Y mouse coorinates mapped to the form size? This could be process intensive, so i'm not sure).

2) Deleting a file. Can it be done without security settings, or is that irrelivent?

3) Would it be worth constructing the file to begin with anyway? It could disrupt the drag drop if the file is large or there are many of them. Is there any way to manage a file constructing without chewing up 100% of the CPU? (Thread perhaps?)

4) What about multiple files? Can the drag drop method handle multiple objects? Construct 5-6 objects by stream, and then enable the drag and drop?

There are a number of problems I can see with this method, but there must be some way to manage it. If the file is being written to or is still open when the drop command is sent, then it won't work for one.

I'm just toying with ideas here.

Any thoughts?

Cata

Re: Drag Drop - Simple Theory - Simple Solution?

Tristan Rhodes16-Dec-03 3:05

Tristan Rhodes

16-Dec-03 3:05

Unless, I don't perform the dragdrop operation immediately, and when the file is completed, I could then pull the file path from the COM method, and move the file using that?

Re: Drag Drop - Simple Theory - Simple Solution?

Heath Stewart16-Dec-03 3:42

Heath Stewart

16-Dec-03 3:42

The_Catalyst wrote:
4) What about multiple files? Can the drag drop method handle multiple objects? Construct 5-6 objects by stream, and then enable the drag and drop?

Yes it can. The DataFormats.FileDrop clipboard format is a managed string[] array, which gets marshaled correctly so that Windows can understand it.

You know, in as many questions and answers that have been posted about your problem, you have never once mentioned what you are trying to do. Perhaps someone has a better solution overall than what you are trying to do. This may help things.

Also, yes, creating the files when the mouse leaves the form (which is possible) would be incredibly inefficient and would probably just piss-off your users since the CPU would spike and their shell would appear to hang for a while. The stream way I've mentioned before is about the only way to know when something is requesting the file(s) that you are providing.

The Objective / Solution

16-Dec-03 4:27

I have a list view, and a tree view. They are synchronised (The active folder in the tree view displays it's contents (an ArrayList assigned the the TAG object) in the list view).

I can drag stuff between folders in the tree view, and rearange the list view all well and good.

It's similar to winzip with winMPQ elements, only I intend to add methods to the archive to automaticaly present a content map to a program that wishes to access it.

While I have written a program to import and export files and objects via a fileDialogBox, i would like to implement drag and drop of list view objects (or the data they represent) into the list / folder view both two and from the windows enviroment.

I have the dragging from windows enviroment working, extracting the data and adding it to the TAG, then refreshing the listview, and performing an Icon lookup based on the extention.

The objects I would like to drag out of the enviroment will have their data extracted and assigned to ObjectData.Data, and the filepath will be constructed from *name*.*extention*.

<br />
struct ObjectData<br />
{<br />
object data;<br />
string name;<br />
string extention;<br />
}

Looking at it now, it may well be worth my while using the predefined ObjectData object instead of my own version. That should not be too difficult to accomplish, but which version should I use? COM, or .NET?

I can implement the COM object that I need, but I am unsure of how to manage the transition between COM DataObjects and the .NET version. When, where and how, if at all, should they be replaced? Only for drops outside the enviroment? Or inside as well? Will I have to handle the managed COM objects for internal drops if I want to use it at all?

Cata

Re: The Objective / Solution

Heath Stewart16-Dec-03 5:04

Heath Stewart

16-Dec-03 5:04

You'd probably need to use the COM IDataObject, but you don't translate this to or form the .NET version. It's all P/Invoked calls (like the native DoDragDrop function), structures (like STDMEDIUM and FORMATETC), and interfaces (like IDataObject, IDragSource, and IStrea). The .NET drag-n-drop isn't used in this solution. It is an overly simplified implementation that won't do what you need. I've actually read the IL behind these classes and .NET uses this same approach - eventually the IDataObject is transformed into COM's and the native methods are used, but these are internal and you cannot access them except through reflection (and that would be even harder).

Re: The Objective / Solution

Tristan Rhodes16-Dec-03 5:27

Tristan Rhodes

16-Dec-03 5:27

So i will just have to handle the COM versions? I can't use the .NET drag and drop at all, even for internal moves?

(Just making sure I understand you :p )

Cata

Re: The Objective / Solution

Heath Stewart16-Dec-03 5:29

Heath Stewart

16-Dec-03 5:29

You could use it for internal moves and you can even use the events to trigger the COM routines, but it will be hard distinguishing whether or not you'll need to do .NET or COM routines. Either way, the end result is the same. Remember that the .NET routines, interfaces, etc., are built on top of the Win32 drag-n-drop, so you can still use the .NET events for dropping in your application, but you should use the COM routines to pack the data how you want.

Re: The Objective / Solution

Tristan Rhodes16-Dec-03 6:16

Tristan Rhodes

16-Dec-03 6:16

So overwrite the DoDragDrop method, replace the structures with managed COM structures etc, and just let .NET interact with it in the way it was designed.

The only problem I can see is, will .NET recognise the new method and handle the mouse pointer shape automaticaly? Or is that windows that manges that and determines whether it is a dropable location?

I'm going to assume it's windows and get on with it at some point when I feel better.

God I hate Colds. They ruin thought processes Frown | :(

Cat

Re: The Objective / Solution

Heath Stewart16-Dec-03 6:21

Heath Stewart

16-Dec-03 6:21

No, don't override DoDragDrop. For one, it's not virtual (meaning you have to declare it with the new) keyword. Second, the data parameter expects an IDataObject (or temporary, unformatted Object) from .NET - not COM (type Types, while named the same, are still different Types).

You need to P/Invoke the native DoDragDrop functions. I only meant that you could initiate drag-n-drop using the same event handlers but using the P/Invoked code. Your drop targets can use the managed drag-n-drop events because the data object will by seen by .NET the same way. If you want to support the same formats as the DataFormats class fields, just use the same format IDs as they have (which you can find by using the same strings (check the fields' values) or the IDs, which you can get from the Win32 headers).

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.