|
The ApplicationBase property does NOT change the current directory for file operations. It only affects the loading of assemblies for that AppDomain. An application cannot have more than one "current directory", one for each AppDomain is not possible, and using it is considered an unreliable practice anyway. Change your code to get the path to the .EXE (Application.StartupPath), then use the Path class's Combine method to create fully qualified paths to the plugins.
Dave Kreskowiak
Microsoft MVP - Visual Basic
-- modified at 11:20 Tuesday 18th July, 2006
|
|
|
|
|
Nice one Dave,
Thanks for that - a very precise answer on a subject not many (including me) know about. When you say 'an application' cannot have more than one current directory, do you refer to a Windows process?
Regards,
Rob Philpott.
|
|
|
|
|
Yep. An application, or Process, can have multiple AppDomains, but only one "current directory".
Myself, I follow the philosophy of leaving nothing to chance. I always build and use fully qualified path names, even when then files are in the same path as my application.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
You could set the static Environment.CurrentDirectory property to the same directory as the ApplicationBase.
:josh:
My WPF Blog[^]
|
|
|
|
|
Hi all
I'm writing a simple form which is a launcher of a game using C# with .net framework.
What problem I met is, I need to place some transparent buttons in the form which contains a playing AVI video in the background, but the video in the transparent part of those buttons cannot be properly displayed.
I used a panel to hold the AVI video (using Microsoft.DirectX.AudioVideoPlayback) and a PictureBox to hold the transparent image (PNG format). I did set the background of the PictureBox to transparent, but the color of the transparent part of the Image seems as same as the background color of the form.
Can you help me about this? thanks!
|
|
|
|
|
You might be able to work something out by using the backcolor and forecolor options for the controls and set the color to transparent. ex:
control1->backcolor = Color(0x00000000);
p.s. the code sample is in c++, although it should be close enough for you to work with it in c#, and the color call is in system.drawing.dll
|
|
|
|
|
You can use a transparent (TransparencyKey = BackColor) form above your panel.
|
|
|
|
|
Hi all,
I've recently had to work on a .NET web application. Now, although I've been familiar with .NET for approximately a year now, I'm primarily a Java developer. And while I think .NET is a great idea, there is one thing I don't quite understand about it -- the way exceptions are handled. In particular, I'm dissapointed by the lack of checked exceptions. A method does not need to declare that it may throw an exception, making it harder to manage the propagation of exceptions in your programs.
Perhaps a simple example to demonstrate...
Java:
static void myReadLine(String filename) throws IOException {<br />
BufferedReader reader = new BufferedReader(new FileReader(filename));<br />
return reader.readLine();<br />
}
C#:
static void MyReadLine(string filename)<br />
{<br />
StreamReader reader = new StreamReader(filename);<br />
return reader.readLine();<br />
}
It's pretty obvious what both methods are doing, and that they are doing it in pretty much the same way. The main difference is in how those methods can now be used. In C#.NET, you can call MyReadLine() from anywhere in your code and everything will happily compile. If things go wrong and an System.IOException is thrown in that method, then unless you've done your homework and surrounded the call to MyReadLine() with a try-catch block, your application will crash. With a pretty stack trace printed on the screen. Ungracefully.
In Java, the code will not even compile unless you are explicitly catching that exception when calling myReadLine(). An IOException is a checked exception in Java -- meaning that if it's ever thrown, it must be caught somewhere in your code. Other exceptions, such as, say NullPointerException, are run-time exceptions and do not have to be explicitly caught (although sometimes it's not a bad idea to do so). In .NET, it seems, all exceptions are considered run-time.
Even if you happened to know that StreamReader.ReadLine() throws an exception, there's a fair chance that some methods in your code could throw exceptions without you even knowing it. And if they can, then they will -- at the worst possible time, naturally. So your options are either keep your fingers crossed, or trawl through the documentation, checking for possible exceptions for each method your code is calling. Neither option is particularly appealing. Nor is catching the general System.Exception always a good idea. Whenever something has gone sour, the code that makes the sun shine again should know exactly what when wrong and exactly what to do about it. Catching a general exception just tells your program something went wrong -- no more, no less.
Why am I writing this? If you've read this far, you'll probably agree that sure sounds like a whinge. And you'd be right. But there's more to it. I'd like to ask:
Can someone cast light on why are exceptions being handled this way in .NET? What are the advantages of treating all exceptions as run-time exceptions?
Is it something that you just learn to deal with as a .NET developer? How do you deal with it?
Cheers,
Misha
|
|
|
|
|
Yes there is a rationale behind this.
Anders Hejlsberg (Turbo Pascal inventor, Delphi Lead Architect at Borland and now lead C# architect at MS) does explain why Javas checked exceptions are a nice concept but do break in big projects.
http://www.artima.com/intv/handcuffs.html
HTH,
Alois Kraus
|
|
|
|
|
Thank you. That is a very insightful article. It sheds a lot of light on the topic. The author makes points that are both relevant and valid. While I can't say I agree with all of them 100%, I can now see that there is indeed more than one way to skin a cat.
Of particular interest is his approach to exception handling -- heavier use of the try-finally to free any acquired resources, and a centralised exception handler to actually deal with the exception.
After reading that article, however, one particular paragraph bothered me:
From the article: But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks... But I think we can certainly do a lot with analysis tools that detect suspicious code, including uncaught exceptions, and points out those potential holes to you.
Now, I would like to know -- what publicly available tools like that are out there?
Thanks.
Cheers,
Misha
|
|
|
|
|
misha1983 wrote: what publicly available tools like that are out there?
I don't know of any.
In fact I opened an FR with MS that would have the XML documentation created include any exceptions thrown inside the documented method, just to be sure that they get into the documentation.
My Blog[^]
FFRF[^]
-- modified at 10:33 Friday 14th July, 2006
|
|
|
|
|
Static code analyzers like Reflector (it has a very good API but nearly no docu) can do this to a certain degree. You will never get 100% coverage since today software is plugable/configurable. There is no way to find out what module you did configure into you software. But for a good overview if some big holes are missed static code analyzers (FXCop should also be able to do this to a certain extent) they are surely useful.
Yours,
Alois Kraus
|
|
|
|
|
misha1983 wrote: Can someone cast light on why are exceptions being handled this way in .NET? What are the advantages of treating all exceptions as run-time exceptions?
I would say that the checked exceptions in Java are still run-time exceptions (they get thrown at run-time, not at compile time) it is just that Java has the ability to explicitly declare which exceptions a method will throw as part of the method signature and the compiler just ensures they are either caught or become part of the signature of the calling method.
I would say that the best discipline would be to ensure that, when you document the code, you define which exceptions a method will throw in the documentation. Intellisence in Visual Studio will read the XML documentation and generate appropriate tool tips while you are typing the method name to remind you that exceptions are thrown.
misha1983 wrote: Is it something that you just learn to deal with as a .NET developer? How do you deal with it?
I've never really thought about it before. I was a C++ developer since 1992 before .NET came along and it never had checked exceptions either. In fact, in C++ you could throw any object you liked as an exception - which is probably a worse situation.
Scottish Developers events:
* .NET debugging, tracing and instrumentation by Duncan Edwards Jones and Code Coverage in .NET by Craig Murphy
* Developer Day Scotland: are you interested in speaking or attending?
My: Website | Blog
|
|
|
|
|
Colin Angus Mackay wrote: it never had checked exceptions either.
C++ does have exception specifications with the same syntax. An exception specification in C++ provides a solution that can be used to list the exceptions a function may throw with the function declaration, but it does not force the caller to write code to catch the listed exceptions. I like the C++ way 
Best,
Jun
|
|
|
|
|
Apart from Anders's article at Artima there has been lots of discussion about this (and research) elsewhere on the web. The general consensus seems to be that checked exceptions seem like a good idea at first, but not such a good idea eventually!
However, Spec#, MS's research language, which is a C# superset, does have checked exceptions and I think they provide a rationale for this, given the extra features of Spec#! So maybe some form of them may be rolled back into C#! Confusing, eh?
Kevin
|
|
|
|
|
Hi,
Iam new to .Net programming and this problem is keeping me ideal for last few days.
I like to read the Roles list from the configuration file for a particular form to control the visibility of the web controls.
My web.Config has authorisation like this:
<location path="iApprove/Doctor">
<system.web>
<authorization>
<allow roles="Doctor, ID Specialist, MHS - Guidance Doctor, MHS - Guidance Authorised Approver" />
<deny users="*"></deny>
</authorization>
</system.web>
</location>
But inside that locatiion i have many forms and in one form i need to make few fields invisible for roles Doctors alone.
How can i achieve this? if it is not possible by reading configuration file then please give me some other way of doing it.
Am using .Net 1.1.
I am looking forward some help.
Thanks
Renu
|
|
|
|
|
Hi
U can use the session variable. When use logs in , set the role of that user in session variable. While displaying the forms, check the value of session variable & display appropriate controls
Regards
Manish
|
|
|
|
|
Hi Manish,
Thank you so much for your time.
Actually there is another thing i need to consider. I will explain the situation with example:
A user may be under more than one user group and each group has different functionality.
User1 is under Role1 and Role2
User2 is only under Role2
The specified location can have access by both role1 and role2, but user from only role2 cannot have access to few fields in a page.
So far am having user's role saved in FormAuthenticationTicket as DataUser and i need to check their Roles list with the list specified under the configuration <location> tag to make sure the user is only under role2 to invisible the fields.
I hope it explains well. Now is it possible reading config file's <location>? if so, please tell me how. If not could you please give me few other suggestion to achieve it?
Expecting reply...
Thanks
Renu
|
|
|
|
|
In the ASP.NET 1.0 framework, the Page class has a "User" property. That property has an "IsInRole" method which returns a Boolean value indicating if the logged in user is in the given role. This could be used to set the visibility of your fields:
myControl.Visible = this.User.IsInRole("Doctor");
Jim Conigliaro
jconigliaro@ieee.org
|
|
|
|
|
If I write a program, say in C#, to read and write to a serial port and use the SerialPort class in .NET 2.0, will this program be compatible with machines still using .NET framework 1.1?
|
|
|
|
|
No. To use any 2.0 classes you need the 2.0 framework.
|
|
|
|
|
So if I developed it on a machine using .NET 2.0, compiled it, and moved the EXE to a computer with .NET 1.1, it would fail?
|
|
|
|
|
|
ok, good to know, thank you.
|
|
|
|
|
I think the serial port classes were new in 2.0 so they wouldn't even be in 1.1.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
