|
hi all
while creating windows service can we use config file, if we can so where we will put this file either in "bin\debug\" or in "bin\release"
i have put my file in bin/release folder . but after creating setup when i start this service so it doest not start ,,, any i dea ?
hello
|
|
|
|
|
Put the config file in the same directory as the executable it configures.
|
|
|
|
|
Your setup would normaly install the service to a folder in "program files" ([Manufacturer]\[AppName]). By default, your app.config file should reside here too.
|
|
|
|
|
Hi Frndz,
I have seen many medium & big size co's prefer C# over VB.NET in various web app.
Why is it so?? Because I do not see any reason for this preference as the compilers & CLRs same for both the language.
So still why do co prefer C# over VB.NET?
Regards,
Vipul Mehta
|
|
|
|
|
VB6 was and is a joke. C# carries an association with C++ ( which it does not deserve ) and VB.NET carries the stigma of VB6, which is in part deserved, as a lot of VB6 nastiness does exist in VB.NET, and a lot of people use VB.NET as VB6, by ignoring the new framework features.
But, you're right, in the hands of a skilled programmer, it's rare to find a project where one language does it better than the other.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: VB6 was and is a joke.
That statement may not be PC, but I couldn't agree more.
|
|
|
|
|
Christian Graus wrote: VB6 was and is a joke.
Never really understood why so many C++ers are so hostile to VB. And I have a C++ background myself. Sure it has deficiencies but it was adequate enough for what it did. C++ has deficiencies too.
I'm using VB .NET now and in fact I'm more irritated by IDE deficiencies compared to C# than language features as such.
Christian Graus wrote: as a lot of VB6 nastiness does exist in VB.NET
Are you talking about use of CInt etc? These are in fact identical to Convert.To... despite being in the Microsoft.VisualBasic namespace.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Never really understood why so many C++ers are so hostile to VB
I don't understand the hostility either.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
|
|
|
|
|
Add to this that in most cases C# coders, as compared to VB coders, tend to use better coding habits and exhibit more understanding of OO concepts necessary for organization to implement code re-use, etc.
only two letters away from being an asset
|
|
|
|
|
any langauge purely depends on data types.and c# supports strongly typed.
suman
|
|
|
|
|
Personally I think the choice is company specific. Some people willl have a culture that believe serious development is done in C#, others will think that VB has left the VB6 issues long ago.
If a company has a lot of experience with C++ then they would more likely choose to use C#. I personally have moved from C++ to VB.Net and found it not so easy at first.
Check out ARCast - To VB or not to VB at
http://channel9.msdn.com/shows/ARCast_with_Ron_Jacobs[^]
|
|
|
|
|
C++ based programmers have a completely different mindset than VB programmers.
|
|
|
|
|
I'm curious--what if I said that I have a 100% DbC-compliant implementation working on .NET, and that I can prove it? How much would that be worth to the average .NET developer?
I've been doing a lot of research into DbC in .NET for the past three years and I've managed to come up with an implementation that:
-Language independent. It works on any .NET language (even works on VB.NET, heh  )
-Has full support for Pre/postconditions/invariants
-Completely transparent.
-Supports inheritance for all contract checks (that is, it combines preconditions/postconditions/invariants from parent classes correctly into a single contract check)
-Support for contracts declared on .NET interface members
-Support for attribute-based contracts, similar to XC#
-Assertions are completely debuggable. You can step through them just like any other piece of code that you write.
-Support for parameter preconditions. You can write preconditions and apply them to contracts just as easily as you would in XC#.
-Full diagnostic debugging support. If a precondition/postcondition/invariant fails, we can tell you where it failed, what method called it, and we can even assert on that method that caused it to fail.
-Support for class-based accessibility. This library allows you to write preconditions which actually prevent certain types of callers from accessing your code (similar to Eiffel's class-based visibility). For example, you can use this approach to protect internal parts of your code so that they can only be callable from a particular assembly/type/module. This approach prevents library users from using TypeMember.Invoke() to bypass visibility checks in your code because the code itself can check the type identity of the method caller and throw an exception if an unauthorized attempt is made to call the method. Not bad, eh?
Here's a sample contract definition on a single method called Divide:
<br />
public class MathClass<br />
{<br />
public int Divide(int a, [NonZero] int b)<br />
{<br />
return a / b;<br />
}<br />
}<br />
Where NonZero would be a custom precondition attribute defined as:
<br />
[AttributeUsage(AttributeTargets.Parameter)]<br />
public class NonZeroAttribute : IParameterPrecondition<br />
{<br />
#region IParameterPrecondition Members<br />
<br />
public bool Check(InvocationInfo info, ParameterInfo parameter, object argValue)<br />
{<br />
int value = (int)argValue;<br />
return value > 0;<br />
}<br />
<br />
public void ShowErrorMessage(TextWriter stdOut, InvocationInfo info, ParameterInfo parameter, object argValue)<br />
{<br />
stdOut.WriteLine("Parameter '{0}' cannot be zero", parameter.Name);<br />
}<br />
<br />
#endregion<br />
}<br />
So here's how it works: Every time the method Divide is called, my library (called LinFu, short for Language-INdependent Features Underneath) will check the parameters of your method and throw a preconditionviolationexception if the precondition check fails (much like Kevin McFarlane's approach). If the preconditon check fails, it will call ShowErrorMessage and that will be the message applied to the exception.
(Invariants and postconditions can be applied the same way, but for the sake of brevity, I'll leave it omitted).
Now what makes this interesting is that it doesn't matter whether or not you have access to the original source code--you can modify the compiled binary just as easily as if you had the source code in front of you. In fact, the library can modify the binary both dynamically at runtime AND compile time.
So, call this an unabashed advertisement, if you will
Now, I have to ask the Microsoft research people (and anybody else interested) out there--how much would this be worth to you?
|
|
|
|
|
I would suggest first posting an article on this, preferably with an example that people can try out. Then see what interest it generates. If you eventually want to sell it you probably need to effectively get people beta-testing it for a while.
Also, I assume you are aware that MS Research have Spec#, features of which I assume will make their way into .NET eventually.
Kevin
|
|
|
|
|
Looks interesting. In that example I would prefer NonZeroAttribute to override ToString() to build that message and then the calling code can do what it likes to handle the thrown exception. Also, that Check checks for >0 rather than !=0, but as it's just an example it's OK.
Of greater concern is that Check takes an object (and then tries to cast to int), would it be possible to write a condition that uses generics?
Would you expect users of your code to write their own conditions (which may be just as roughly written as the example)? Or would you include a library of well-written conditions that handle most common situations?
To answer the main question; as I doubt it's nothing I couldn't write myself, I wouldn't pay for it, it's far more fun to write it myself... I would then post it free here on CodeProject.
|
|
|
|
|
PIEBALDconsult wrote: Looks interesting. In that example I would prefer NonZeroAttribute to override ToString() to build that message and then the calling code can do what it likes to handle the thrown exception. Also, that Check checks for >0 rather than !=0, but as it's just an example it's OK.
Allowing the user to override ToString() would be the simpler approach, but I figured that if a check fails, it's better to pass the diagnostic information down to the end-user dev so that they can show exactly what went wrong. In this case, it seems a bit overkill for checking if a single parameter is null, but overall, I think it makes everything easier to debug in the longrun.
PIEBALDconsult wrote: Of greater concern is that Check takes an object (and then tries to cast to int), would it be possible to write a condition that uses generics?
It's possible, but at some point LinFu has to package the method arguments into an array of objects, and IMO, that pretty much negates the use of generics because of boxing issues, and whatnot. On the other hand, if you're worried about a potential InvalidCastException, it's easy enough to inspect the signature of the method through the InvocationInfo.TargetMethod
property and check if it's valid.
The only possible benefit I can see here is the syntactic sugar.
PIEBALDconsult wrote: Would you expect users of your code to write their own conditions (which may be just as roughly written as the example)? Or would you include a library of well-written conditions that handle most common situations?
At this point, you'd pretty much have to roll your own. I haven't had much feedback just yet from different users to build a library of common method checks, so other than the canonical NotNullAttribute and NonZeroAttribute, that's just about it.
|
|
|
|
|
Philip Laureano wrote: Allowing the user to override ToString() would be the simpler approach, but I figured that if a check fails, it's better to pass the diagnostic information down to the end-user dev so that they can show exactly what went wrong
I meant rather than the ShowWhatever method that prints to stdout.
Philip Laureano wrote: and check if it's valid.
It just seems poor style, unless you mean to throw InvalidCastException.
I would do something more like:
<br />
if ( Value is int ) <br />
if ( (int) Value == 0 )<br />
throw the normal exception<br />
else <br />
throw something that explains the problem<br />
<br />
return true ;<br />
or
<br />
if ( !( Value is int ) || ( (int) Value == 0 ) )<br />
throw the normal exception<br />
<br />
return true ;<br />
|
|
|
|
|
PIEBALDconsult wrote: Philip Laureano wrote:
and check if it's valid.
It just seems poor style, unless you mean to throw InvalidCastException.
The first few versions of LinFu that I had actually allowed users to throw specific types of exceptions, but to me, it made more sense to split the process into two parts:
1.) Allow users to check the precondition/postcondition/invariant and show whether or not it passes (hence, the boolean part).
2.) And if the check fails in debug builds, the debugger will assert with the message that you write to the stdOut TextWriter. (In release builds, however, it will specifically throw a Pre/Post/InvariantViolationException.)
While it is possible to throw exceptions of your own, I strongly recommend against it.
The whole point here is that exceptions thrown from DbC checks should never be caught. IMHO, they should fail hard so that it forces the programmer to fix whatever violated the precondition/postcondition that caused the check to fail.
However, I can't completely dismiss having users throw specific types of exceptions from checks altogether--if one does throw an exception for a check (whether it is a pre/post/invariant), I could easily catch it and wrap it into the InnerException property of a Pre/post/invariantViolationException.
p.s. Thanks for the interesting feedback!
|
|
|
|
|
This
the code itself can check the type identity of the method caller and throw an exception if an unauthorized attempt is made to call the method.
has me wondering how you do that.
I'm trying to have a method determine who called it and finding limitations. (As posted in this forum.)
|
|
|
|
|
I developed a c# application for my roomate's laptop ,I tried run my exe file on his laptop and I was getting an error message <app.exe has="" ancoutered="" a="" problem="" and="" need="" to="" close=""> so after spending many hours trying to figure out whats going on, I realised that my crystalReport portion of the code was causing the error, so I had take it off the project .
so do you guys know why it wont run if I use CrystalReport ???
ps: the application runs fine in myh laptop I guess cause I have the compiler, my roomate's laptop has only the .framework.
thanks in advance
aPerfectTool
|
|
|
|
|
Is the Crystal Reports redistributables installed on your roommate's computer?
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
I'm writing a method (MethodA) that needs to know what method of what class
called it (so it can say, "ClassX called me"). Without having to pass the
type down the chain.
To do this, MethodA walks back up the StackTrace and use GetMethod() looking
for the first method it finds with a custom attribute I created.
The problem I'm having is with derived classes which don't override a method
that calls MethodA. It turns out (in this case) that both DeclaringType and
ReflectedType return the base type rather than the derived type.
I boiled this down to:
namespace Template
{
public class ClassA
{
public virtual string
Declaring
{
get
{
return ( (new System.Diagnostics.StackTrace ( 0 , false
)).GetFrames() [ 0 ].GetMethod().DeclaringType.Name ) ;
}
}
public virtual string
Reflected
{
get
{
return ( (new System.Diagnostics.StackTrace ( 0 , false
)).GetFrames() [ 0 ].GetMethod().ReflectedType.Name ) ;
}
}
}
public class ClassB : ClassA
{
}
public class Template
{
[System.STAThread]
public static void
Main
(
string[] args
)
{
ClassA a = new ClassA() ;
ClassB b = new ClassB() ;
System.Console.WriteLine ( a.Declaring ) ;
System.Console.WriteLine ( a.Reflected ) ;
System.Console.WriteLine ( b.Declaring ) ;
System.Console.WriteLine ( b.Reflected ) ; // Shouldn't this
report ClassB?
return ;
}
}
}
The result is:
ClassA
ClassA
ClassA
ClassA
I can certainly understand why DeclaringType return the base type, but I had
hoped that ReflectedType would return the actual type that called it, and
that the result would be:
ClassA
ClassA
ClassA
ClassB <- note
How can I do this?
Am I doing something wrong?
Is there a better way?
Is ReflectedType broken?
(I posted this on MSDN too, and the response was more or less "that can't be done", so I figured I'd get a second opinion here.)
-- modified at 10:56 Monday 27th November, 2006
|
|
|
|
|
The only way I can see that being done is if you can actually get a reference to the actual method caller, and call GetType() on it.
AFAIK, the stack frame only keeps a record of method calls, and not the caller instances, so sorry, we're both out of luck.
|
|
|
|
|
Yeah, that's how it seems to be. But it sure would seem to make more sense the other way. If I am executing Derived.Method, then the frame should have a Derived.Method even though Method is declared in Base and not overridden. I mean come on, is it inherited or not?
It's not affecting me very much, I just need to walk back along the stack a little further to find an actual method that's declared in the derived class in order to find the attribute.
P.S. Did you run into the same thing? Do you have a workaround?
|
|
|
|
|
I don't have a workaround for it since I really didn't need to examine the caller for any embedded attributes. The only only workaround I could see for that is if you were to manually add type information that states which method calls which--and that would be one ugly hack to pull off.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
