|
And there are web services which you can use.
|
|
|
|
|
How can I use 3D modules(Such as DirectX or OpenGL)in my programming...Please guide
Best regards,
|
|
|
|
|
That's far too broad a scope for anybody to stand a chance of answering here on the boards. If you narrow the scope of your question, you might get more help. Beyond that, try to google for DirectX tutorials C# and OpenGL tutorials C#.
|
|
|
|
|
Hi,
I am using Nokia 6630 for sending sms from my pc to mobile via gsm modem.I have connected all this through serial cable.I am using C# tool but now i have just used the following commands in hyperterminal and it gave following responses:
AT
OK
AT+CMGF=?
+CMGF: (0,1)
OK
AT+CMGF=1
OK
AT+CMGW="0123456789"
> HI
+CMGW: 26
OK
Everything is OK but message is not sent to mobile.I dont know where is the problem.Can anyone solve this?? Thanks in advance.
Regards,
Aeman
modified on Wednesday, March 2, 2011 5:43 AM
|
|
|
|
|
|
Hello
If I set some secret/sensitive information in AppDomain ...
AppDomain.CurrentDomain.SetData(SOME_SECRET_KEY, PrivateKey)
How can I protect it from third party dll loaded on demand? For example, in our application which hosts third party dll,
<br />
MaliciousLib = Assembly.LoadFrom(DllPath);<br />
oService = MaliciousLib.CreateInstance("xxxx.xxxx.xxxx");<br />
ISomeService Service = (ISomeService) oService;<br />
Service.DoSomeWork(...);<br />
Here, MaliciousLib can also access AppDomain and retrieves secret key.
I'm considering loading third party dll's into separate app domain (In which case they can't have access to the main AppDomain right...? In which case, next logical question - how 3rd party lib communicates back to main assembly... while it can't access main assembly's AppDomain variables, perhaps "function call return" would suffice ...)[^]
But I just done some testing, User dll methods can still access AppDomain.CurrentDomain!
<br />
oSecret = AppDomain.CurrentDomain.GetData("KEY1");<br />
Many articles discuss theories surrounding AppDomain, how one process can host multiple AppDomain and disaster occurring in one won't bring down the whole process - but really? Thought that's .NET v1 behavior - from v2 on disaster in one AppDomain will bring down the whole process. Also, regarding Get/SetData from security perspective, there's nothing on Google. From my experiment, there isn't any security control on Get/SetData![^]
So really how to protect main app from loaded third party components? Any suggestion?
dev
modified on Wednesday, March 2, 2011 11:25 PM
|
|
|
|
|
Hi
Assembly.GetExecutingAssembly - can we get "Key" which signed the assembly?
I examined the internals of Assembly using Visual Studio Watch window, I found properties such as CodeBase, EntryPoint, Evidence, FullName, GlobalAssemblyCache, ImageRuntimeVersion ... but didn't find anything which resembles Key ...
Thanks
dev
|
|
|
|
|
|
<br />
***** Program.cs ***** <br />
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
using System.Reflection;<br />
using System.Security.Policy;<br />
<br />
using UserUtil;<br />
using SimpleUtil;<br />
<br />
namespace TestAppDomain<br />
{<br />
class Program<br />
{<br />
public const string KEY1 = "KEY1";<br />
public static AppDomain UserDomain = null;<br />
<br />
static void Main(string[] args)<br />
{<br />
Assembly UserAssembly = null;<br />
Object oProvider = null;<br />
SimpleUtil.IServiceProvider UserProvider = null;<br />
<br />
try<br />
{<br />
AppDomain.CurrentDomain.SetData(KEY1, "PrivateKey");<br />
<br />
UserDomain = AppDomain.CreateDomain("UserDomain");<br />
UserDomain.SetData(KEY1, "Sh*t!");<br />
<br />
UserAssembly = Assembly.LoadFrom("UserUtil.dll");<br />
<br />
oProvider = UserDomain.CreateInstanceFrom("UserUtil.dll", "UserUtil.ServiceProvider").Unwrap();<br />
<br />
if (oProvider != null)<br />
{<br />
if (oProvider is SimpleUtil.IServiceProvider)<br />
{<br />
UserProvider = (SimpleUtil.IServiceProvider)oProvider;<br />
<br />
UserProvider.DoWork("Calling UserProvider.DoWork");<br />
}<br />
}<br />
}<br />
catch (Exception Ex)<br />
{<br />
Console.WriteLine(Ex.Message);<br />
}<br />
<br />
return;<br />
}<br />
}<br />
}<br />
<br />
*** SimpleUtil.ServiceProvider ***<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
using System.Runtime.Serialization;<br />
<br />
namespace SimpleUtil<br />
{<br />
[Serializable()]<br />
class ServiceProvider : SimpleUtil.IServiceProvider<br />
{<br />
public void DoWork(string Message)<br />
{<br />
Console.WriteLine("SimpleUtil.DoWork");<br />
return;<br />
}<br />
<br />
public ServiceProvider()<br />
{<br />
return;<br />
}<br />
<br />
public ServiceProvider(SerializationInfo info, StreamingContext context)<br />
{<br />
return;<br />
}<br />
<br />
public void GetObjectData(<br />
SerializationInfo info,<br />
StreamingContext context<br />
)<br />
{<br />
return;<br />
}<br />
<br />
}<br />
}<br />
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
using System.Runtime.Serialization;<br />
<br />
namespace SimpleUtil<br />
{<br />
public interface IServiceProvider : ISerializable<br />
{<br />
void DoWork(string Message);<br />
}<br />
}<br />
<br />
<br />
***** UserUtil.ServiceProvider *****<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
using System.Runtime.Serialization;<br />
<br />
using SimpleUtil;<br />
<br />
namespace UserUtil<br />
{<br />
[Serializable()]<br />
public class ServiceProvider : SimpleUtil.IServiceProvider<br />
{<br />
public void DoWork(string Message)<br />
{<br />
object oSecret = null;<br />
string secret = null;<br />
<br />
oSecret = AppDomain.CurrentDomain.GetData("KEY1");<br />
if (oSecret != null)<br />
{<br />
secret = (string)oSecret;<br />
Console.WriteLine("UserUtil.DoWork - secret=" + secret);<br />
}<br />
else<br />
{<br />
Console.WriteLine("UserUtil.DoWork - secret=NULL!");<br />
}<br />
return;<br />
}<br />
<br />
public ServiceProvider()<br />
{<br />
return;<br />
}<br />
<br />
public ServiceProvider(SerializationInfo info, StreamingContext context)<br />
{<br />
return;<br />
}<br />
<br />
public void GetObjectData(<br />
SerializationInfo info,<br />
StreamingContext context<br />
)<br />
{<br />
return;<br />
}<br />
}<br />
}<br />
<br />
So, this is not going to work if intention of loading third party dll into separate appDomain is security. Not to mention, there are ways to enumerate app domains in the executing process[^]
Any suggestion how we can save sensitive data in AppDomain (using SetData/GetData) "safely"!?
Thanks
dev
modified on Wednesday, March 2, 2011 10:42 PM
|
|
|
|
|
thanx....
modified on Wednesday, March 2, 2011 5:23 AM
|
|
|
|
|
Do not repost[^], it is rude. This might be urgent for you, but not for the people who volunteer their time.
|
|
|
|
|
Thanks for what?
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
Trolls[ ^]
|
|
|
|
|
I would like to display a picture in my WPF application, where the picture is loaded from a resource file. I'm not interesting doing this with C# code, only with XAML code. But I have no idéa how to pull this off. Please help me.
This is what I have done:
1) Created a new WPF application called: WpfApplication1
2) Created a resource file called: Pictures.resx
3) Added the picture into the resource file
4) The picture is called: CELabel, in the resoruce file explorer window
5) Automatically a folder in in my application is created, called Resources, containing the picture: CELabel.png
Now I would like to code the appropriate XAML code to display the picture. So I try this:
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
<Image Source="/Pictures/CELabel.png"></Image>
</Grid>
</Window>
And of course the damn compiler results in an error:
Could not find a part of the path 'C:\Pictures\CELabel.png'
Yes, of course the resource file is not recognizable in the XMAL editor and then my picture cannot be loaded.
How do I pull this off? I'm sure this is rediculious easy when knowing how...
|
|
|
|
|
You've stated you don't want to do this in C#, so why ask it in the C# forum? You should ask WPF questions in the WPF forum.
|
|
|
|
|
Wopsi... 
|
|
|
|
|
Topaz you 're missing the point with usage of Resource.rsx. Just create folder, put a picture in it , drag a image control to your form in properties set path to your picture and that's it!
cheers
|
|
|
|
|
I am new to databases and C#. In my main program in C#, I can open a connection to postgresdb , do some queries and close connection afterwards. But, I don't like to open it up every time I query the db, is there a way where the db stays opened for the life of the application, so I can query things anytime through out the life of the program and only close when I kill the app.... How is it normally done in big apps that query db quite often?
Is this the right way of doing it, or am i missing something here?
Thanks
|
|
|
|
|
You can do it by database pooling.
See this link to get more info about it;
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx[^]
In fact closing the connection is recommended. Here is a quote from the documentation:
It is recommended that you always close the Connection when you are finished using it in order for the connection to be returned to the pool. This can be done using either the Close or Dispose methods of the Connection object. Connections that are not explicitly closed might not be added or returned to the pool. For example, a connection that has gone out of scope but that has not been explicitly closed will only be returned to the connection pool if the maximum pool size has been reached and the connection is still valid.
|
|
|
|
|
Thanks for the article. It sounds a bit expensive and kinda boring though, so if my app has to access the db 100 times, then I would have 100 connections and closes! Yikes!
|
|
|
|
|
So? If you're hogging a $1,000 license and not using it, your manager goes "Yikes!", not you.
|
|
|
|
|
Software2007 wrote: I can open a connection to postgresdb , do some queries and close connection
afterwards. But, I don't like to open it up every time I query the db
Tough. That's the "best practice" method to use.
Software2007 wrote: is there a way where the db stays opened for the life of the application, so I
can query things anytime through out the life of the program and only close when
I kill the app
Bad idea. Database connection licenses are expensive. So, to minimize costs, you are expected to open the connection, use it, then close it as soon as possible so another application can use the connection license on the server.
Think about it. You open a connection for the life of your app, then your app crashes or the network connection goes down, but the SQL connection is never released. Now you've got a connection license being used on the server, but never being used until it's cleared out manually or the connection times out on the server for inactivity.
Software2007 wrote: How is it normally done in big apps
Open the connection, query it, close it.
|
|
|
|
|
thanks for the clarification. Again, I am a newbie to db stuff, but in my little brain, I was thinking may be they have soft/virtual connections or something like that where it wouldn't be so expensive and dramatic. I must have been living in fantasy land!
Thanks again
|
|
|
|
|
Software2007 wrote: am i missing something here?
Big style. It's called scalability. Database connections are expensive resources, and should be treated as precious resources.
Software2007 wrote: But, I don't like to open it up every time I query the db
So, laziness is a virtue in your world?
Software2007 wrote: In my main program in C#, I can open a connection to postgresdb , do some queries and close connection afterwards.
Is it a desktop application? If it's a web application then you can't do this anyway, so you might as well get used to the idea of acquiring the connection at the last minute and releasing it as soon as possible.
Here's a poser for you. Suppose you open your connection at the start of your application and your code relies on this connection being open. Now, suppose that the database crashes and restarts between you querying it. What do you think will happen the next time you issue a query? If you guessed that the code will fail, go to the top of the class. If you think you can rely on the connection always being available, slap yourself around the head with a pink halibut and call yourself Ethel.
|
|
|
|
|
Good answers. I knew the whole costly issue and the concequences of crashing while executing, but I was hoping that I was wrong and there was a more efficient way.
|
|
|
|
|
Write yourself a wrapper class that opens up the connection for you when you execute your SQL if you're worried about remembering to do this.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
