|
No.
I want to put it in my application and file the file if it exist. The file is located in a website , not in the computer.
If there is no way to search for a file in website.
How can i check if a URL exists?
|
|
|
|
|
You can't unless u own the website but u can ping it or use HttpRequest
|
|
|
|
|
OK,
So how can i check if the website works? i mean if URL works...
|
|
|
|
|
Try to download a bit from it?
|
|
|
|
|
There is no a way to know a if a url is valid or not untill and unless you make a request to that url.
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
|
|
|
|
|
OK thanks.
But how can i write this request? can you show me a code for it?
|
|
|
|
|
Google is always a good place to start. Have a look at This Website[^]
Seems to be exactly what you want to do.
Excellence is doing ordinary things extraordinarily well.
|
|
|
|
|
Ok thanks, It's good idea but it wont work for me (site problems- no matter).
I prefare to check if the URL is working or not? i mean to make a request to it... How can i do it?
|
|
|
|
|
Does anyone has an answer for me?
|
|
|
|
|
michaelgr1 wrote: How can i find a particular file (check if exist) in this site?
If you have a URL, issue a HTTP request and see whether you get a 404?
|
|
|
|
|
hello
Need clarification on why we have no C# virtual destructor - here's my understanding.
1. Unmanaged resources are freed by calling Dispose (true/false), managed resources are freed by call to Dispose(true).
2. Managed memory is freed by call to Dispose - Base class should mark Dispose virtual, Derived class should explicitly "override" base class Dispose and "Base.Dispose" should be called in Derived.Dispose (this way both Derived/Base Dispose are called in chain)
Question:
1. Should we make Base.Finalize (~Base really in C# syntax) virtual? Should we implement Derived.Finalize (~Derived in C# syntax)?
2. C++ destructor is C# destructor (or Finalizer) - now SINCE we really want to release resource (expensive ones in particular) in Dispose (deterministically, unlike ~Derived or ~Base), what really I'm asking is, why not "Virtual destructor" same style as C++: http://www.codersource.net/cpp_virtual_destructors.html[^]
In C++, if you declared destructor virtual, and "delete oDerived", BOTH destructor from Base and Derived are invoked (~Derived then ~Base). Why is this NOT the behavior in C#? That you need to call Base.Dispose explicitly in Derived.Dispose, relying on programmer to make sure both are called? Seems like C++ virtual destructor is cleaner?
Thanks
REF:
http://www.codersource.net/cpp_virtual_destructors.html[^]
http://msdn.microsoft.com/en-us/library/b1yfkh5e(VS.71).aspx[^]
dev
|
|
|
|
|
devvvy wrote: Should we make Base.Finalize (~Base really in C# syntax) virtual? Should we implement Derived.Finalize (~Derived in C# syntax)?
It's virtual, and the C# compiler doesn't allow you the option of making it non-virtual. Take a look at the generated IL if you don't believe it. For the below C# code.
class A
{
~A() { Console.WriteLine("A"); }
}
class B : A
{
~B() { Console.WriteLine("B"); }
}
Here's how the IL looks.
.class auto ansi nested private beforefieldinit A
extends [mscorlib]System.Object
{
.method public hidebysig specialname rtspecialname instance void .ctor() cil managed
{
}
.method family hidebysig virtual instance void Finalize() cil managed
{
}
}
Note that Finalize is indeed virtual.
devvvy wrote: C++ destructor is C# destructor (or Finalizer) - now SINCE we really want to release resource (expensive ones in particular) in Dispose (deterministically, unlike ~Derived or ~Base), what really I'm asking is, why not "Virtual destructor"
The C# destructor (Finalizer) is not the equivalent of a destructor in C++, it's unfortunate that the syntax for both of them is the same. You're right about Dispose not being automatically chained up though - I guess that's because it's not really a part of the CLR. C# (and the BCL) provide the functionality through the IDisposable interface, and chaining up for Dispose would mean that other interface methods of any interface should also chain up. There's also the possibility that the base class doesn't actually implement IDisposable as well.
devvvy wrote: In C++, if you declared destructor virtual, and "delete oDerived", BOTH destructor from Base and Derived are invoked (~Derived then ~Base)
Again, it happens for finalizers in .NET, but not for IDisposable. Again, it's because IDisposable is not an intrinsic part of the CLR, and not all objects implement IDisposable.
C++/CLI actually provides deterministic "dispose" functionality.
ref class A : public IDisposable
{
!A() { Console::WriteLine("Dispose for A"};
};
void Main()
{
{
A a;
}
A ^a = gcnew A();
}
|
|
|
|
|
Thanks Senthil
Just a thought, despite in IL code finalizer (or C#'s destructor) is virtual - does CLR automatically call BOTH (like in C++):
(a) ~Base
(b) ~Derived
Also don't you think it's more clean and reliable if C# Disposable gets invoked the same way C++ virtual destructor does? That BOTH Base/Derived are invoked?
dev
|
|
|
|
|
devvvy wrote: Just a thought, despite in IL code finalizer (or C#'s destructor) is virtual - does CLR automatically call BOTH (like in C++):
(a) ~Base
(b) ~Derived
Yes, the base class finalizer will be invoked at the end of the derived class finalizer.
devvvy wrote:
Also don't you think it's more clean and reliable if C# Disposable gets invoked the same way C++ virtual destructor does? That BOTH Base/Derived are invoked?
I agree, it is cleaner. To explain why it is not done right now,
interface ISome
{
void DoSome();
}
class BaseSome : ISome
{
public virtual void DoSome() { Console.WriteLine("BaseSome"); }
}
class DerivedSome : BaseSome
{
public override void DoSome() { Console.WriteLine("DerivedSome"); }
}
void Main()
{
ISome some = new DerivedSome();
some.DoSome();
}
Would you expect DoSome to chain i.e. print "DerivedSome" and "BaseSome"? You wouldn't, because you've overrode the method to have custom behavior. Calling the base class method might be useful in some situations, but there's no way the language can force all overridden implementations to call the base implementation at the end/beginning.
Because disposal is exposed through IDisposable , an interface like ISome , what you expect cannot happen unless the C# compiler treats the interface as a special case.
The reason why it doesn't have to do this for finalizers is that the finalizer is declared in System.Object , which every .NET type must derive from.
|
|
|
|
|
S. Senthil Kumar wrote: ref class A : public IDisposable
{
!A() { Console::WriteLine("Dispose for A"};
};
void Main()
{
{
A a; // Create object with deterministic dispose semantics.
} // !A() will be called.
Actually this is non deterministic approach. GC is calling the finalizer, not the code. In C++/CLI, destructor and finalizer are different. To make it deterministic you need something like
ref class A{
public:
~A()
{
Console::WriteLine("~A()");
}
protected:
!A()
{
Console::WriteLine("!A()");
}
}
int main()
{
A^ a = gcnew A();
delete a;
A a1;
A^ a2 = gcnew A();
return 0;
}
|
|
|
|
|
I guess I got the symbol wrong (! instead of ~).
And the compiler generates a bunch of code when generating the actual Dispose and Finalize methods - calling GC.SuppressFinalize from ~A is one example.
|
|
|
|
|
devvvy wrote: Unmanaged resources are freed by calling Dispose (true/false)
Only true if you've implemented your Dispose to free unmanaged resources.
devvvy wrote: managed resources are freed by call to Dispose(true).
False.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks - to point#2 whhy you said I'm wrong?
managed resource is freed by Dispose method
but managed memory is freed by indeterminstic garbage collection when no outstanding reference to the object exists?
dev
|
|
|
|
|
devvvy wrote: to point#2 whhy you said I'm wrong?
I'm just saying you have no control over when managed resources are released.
Implementing IDisposable does not change that...IDisposable is meant for
unmanaged resources.
I got the feeling from your post that you felt IDisposable would give
you some kind of deterministic cleanup of managed resources, which is
not the case
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
|
Aren't we being a little pedantic here?
Consider a class like this
class Foo
{
StreamReader reader;
IntPtr handle;
public Foo()
{
}
}
Now I would dispose the StreamReader and close the IntPtr handle inside Dispose(true), but will only close the handle inside Dispose(false).
I guess it boils down to whether you consider StreamReader to be a managed resource, or a managed wrapper over an unmanaged resource. I would say it is a managed resource, given that it has a Dispose/Close and a finalizer.
|
|
|
|
|
S. Senthil Kumar wrote: Aren't we being a little pedantic here?
I suppose to you, yes, but I didn't reply to you.
Sure, you often need to know if your managed objects hold unmanaged resources and free
those resources as deterministically as you can if you need to....but still,
calling a class' Dispose doesn't mean you've freed the managed object, which was my point
to devvy.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
devvvy wrote: Managed memory is freed by call to Dispose
No. This is the main difference for a memory management system that has a garbage collector: It's the garbage collection that frees all managed memory, that can not be done any other way. The garbage collector removes any objects that has no references to it, so to get an object collected you just make sure that there is no reference to it.
If an object has no references to it, the references that it contains are not considered as active by the garbage collector. Therefore, if an ojbect only references managed objects (that don't implement IDisposable), you don't have to do anything at all when releasing the object. At the moment when the object is up for garbage collection, all it's child objects are automatically up for garbage collection (unless they are also referenced from some other object).
There is no destructor in C#, like there is in C++. There is no reference counting going on, so at the moment when you remove the last reference to an object, nothing happens. When the garbage collector notices that the object can be collected, but it has a finalizer method (that uses the same syntax as a destructor in C++), the object placed in the finalizing queue. A background thread is working the queue, calling the finalizer method of each object, and after that the object is a regular managed object that the garbage collector can remove.
The finalizer method is only used as a backup for when the Dispose method is not called properly. The Dispose method is the normal means of controlling the life cycle of an object.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
... i think I mentioned "managed resource" (not memory) freed by Dispose.
dev
|
|
|
|