|
I want to run my .NET application from client PC. .NET application will be placed on server. When I run the app, it gives security error (.NET security policy). How do I solve this? I've search about this on the internet, but could not find anything that solve my problem. It seems complicated. Anyone knows any simple article? Thanks.
|
|
|
|
|
Applications running in the Intranet have less rights than ones running on the computer you are using. The simplest fix is to run it from each machine. If you need to run it from the server you have to manually give it rights on the machine through the .Net Configuration MMC.
The way I solve this problem, and there are some reasons this won't work, but it does in most cases, use ClickOnce. It will install on each computer and check for the most updated version automatically(depending on settings), as well as you have the choice to allow it to run only online(your choice), or allow it to be installed and ran anytime.
Hope this helps, or at least sends you in the right direction.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
I previously run it from each machine. I want to try different approach. It is quite hard upgrading the application. I have to visit each machine, or ask them to update it by them self.
|
|
|
|
|
The previous post is correct in explaining the reasons and one way to fix the problem. The other option if your program is .NET 2.0 or higher is to upgrade the client machines to .NET 3.5 SP1 (the newest). That will change the default security policy of programs running from the network to match the policy of programs running from the local machine.
|
|
|
|
|
Should I use my app.config file or the Resources.resx in VS2008 to store the connection string for my DB?
I am not sure which one would be better should I later on decide that I want to give the user the option to edit this.
|
|
|
|
|
The resx files are being compiled into your assembly, so you'll not be able to change stuff in it without recompile.
If you plan to give users possibility to change the stuff choose appconfig
Regards,
Lev
|
|
|
|
|
Ok, Thankyou very much! I'll do that.
|
|
|
|
|
Lev Danielyan wrote: If you plan to give users possibility to change the stuff choose appconfig
I agree with this recommendation. If it's a setting you want the user to be able to configure use the app.config file. resx files are for more fixed resources that only you provide.
Lev Danielyan wrote: so you'll not be able to change stuff in it without recompile
Not quite strictly true. Resources can be compiled into satellite assemblies so you can provide a new set of resources without recompiling the app. (This is mainly used for things like internationalisation & localisation. a satellite assembly will be produced for all the different languages the app is used in).
Simon
|
|
|
|
|
Right, but you will still need to recompile the satellite assemblies 
Regards,
Lev
|
|
|
|
|
hello all
which of the follwing is safer to use
this.Dispose()
OR
this.Close()
Wht is the fundamental difference btwn these two
Thanks
TJS
|
|
|
|
|
TJS4u wrote: this.
Well it depends what Type "this" is.
In some cases Streams/IO and such, they are fairly comparable. Dispose will normally call close. If an object is disposable you should always call dispose when you are finished with it to ensure the finaliser is suppressed. Normally it's ok to just call dispose, but there is no harm in closing explicitly first just to be safe.
For some types of objects, like Forms, close has a specific meaning. Close() will close the form. Dispose will probably also call close, but in many cases you may want to close the form, but still keep the object to do some work with before you are ready to dispose of it.
Simon
|
|
|
|
|
Close() might eventually call Dispose(), actually depends on the class implementation, whereas Dispose must be defined if IDisposable is implemented for resource cleanup
Use using clause;
using(resource) {
}
This will automatically dispose your resource (say a stream), if it implements IDisposable interface
Regards,
Lev
|
|
|
|
|
Close and Dispose for most classes seem to be very close. And in many cases Dispose will call Close. But, the fundamental difference is that Close has the class Dispose alot of its objects, while Dispose actually Disposes the object you are calling it on.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
As it was already said it depends on actual type. For example with sqlconnection object close() and dispose() do the same thing. For other types you can use Reflector to see what dispose() and close() do and compare them.
|
|
|
|
|
To find the difference between the two in a specific instance, .NET Reflector on the type you'd like to examine. You can download it for free from redgate.com.
Scott P
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin
|
|
|
|
|
while working with winfroms in c# i found no of problems
1. when i manually modify my designer.cs surface. Such as checking the attributes. i lost my designer view. And having a massege that "the code within the initilizecomponents is generated by designer and should not be manually modified. Please remove any changes and try opening designer surface again "
Any solution....
2. How can we set the FormBorderStyle in c#
|
|
|
|
|
|
you mean that there is no solution for that?
i have modified that file and when i run my application, what it shows its according to that modified code.
|
|
|
|
|
Solution to what? If you get another appearance of you controls, change it back. If you are getting an error, please post it.
Regards,
Lev
|
|
|
|
|
Christian Graus wrote: you should never modify that file. Apart from anything else, it's regenerated by the IDE, so you're wasting your time
Generaly I agree but sometimes you need to go into it to solve problems.
Also I frequantly use it to see how a control gets initialized and added.
|
|
|
|
|
Well, sometimes you're just forced to edit the _designer.cs (like making some changes without the studio ) But of course you should really know what you are doing.
Regards,
Lev
|
|
|
|
|
as Lev said above,"sometimes you're just forced to edit the _designer.cs"
it means when ever i manually change my Designer.cs
i would not able to see my form view?
|
|
|
|
|
hotthoughtguy wrote: it means when ever i manually change my Designer.cs
i would not able to see my form view?
Not exactly.
You see the designer generated code is being compiled on-the-fly when you open the design view. So, if you do some changes which won't compile (e.g. syntactic error and such), you'll end up with not working design view.
Let me say again, you should really know what you are doing, when modifying designer generated code.
Regards,
Lev
|
|
|
|
|
Christian Graus wrote: it's regenerated by the IDE, so you're wasting your time
That's true, but I go in sometimes to change a component class to a non-system class, and the designer keeps it, even after regenerating (in fact, it fully qualifies the custom class with the namespace). Granted, you should avoid manually changing the file, it is possible to do.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
ok thanks a lot 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
