|
as title,
Develope Tool in PPC,C#???
i do want to get the tool i can use it develop pragrom in PPC
thank you~
|
|
|
|
|
You can do this using Visual Studio with the Smart Device project type.
«_Superman_»
|
|
|
|
|
thanks
but i waner develope pragroms in PPC
for example Python for windows mobile
|
|
|
|
|
A PocketPC is a smart device?
I are troll
|
|
|
|
|
i cant find a good tool about c# in PPC
now using PythonCE :P
|
|
|
|
|
ox0101 wrote: i cant find a good tool about c# in PPC
You don't have Visual Studio?
only two letters away from being an asset
|
|
|
|
|
Hi all ,
What i want to understand is , why isn't it enough to sign with a public key .
Public key guarantees that either my code or its hash hasn't been tampered .
Private key -as I've been told - guarantees the identity of who made the assembly , how is that ??
Assume that i made a bad code , and signed it with private and public key that match , and then claim that this assembly has been made by Microsoft .
What's the purpose of signing with private key before shipping the dll ?
Another question ,
What happens to the delayed-public-signed hash code when i finally sign with a private key (just before release) ?
|
|
|
|
|
bolly-81 wrote: Private key -as I've been told - guarantees the identity of who made the assembly , how is that ??
Because the key is private to you. You don't ever give the private key to anyone else. The only person that could have made the assembly is the person with the private key.
bolly-81 wrote: Assume that i made a bad code , and signed it with private and public key that match , and then claim that this assembly has been made by Microsoft .
But your private key would not match Microsoft's private key, and so you are unable to do that.
bolly-81 wrote: What's the purpose of signing with private key before shipping the dll ?
To authenticate where the assembly came from. As I said, only you have the private key.
|
|
|
|
|
I think you're misunderstanding how the public/private key thing works. You encrypt something (or sign something) with either key (it, technically, doesn't matter which,). This creates an encrypted package that only the other key can decrypt. So, of the case of signing an assembly, you sign with the private key (the one you give to noone else on this planet!), and only the public key (the one you give to everyone) can verify the signature on the assembly. If the public key doesn't work, the assembly wasn't signed with the matching private key, thereby warning the code/user the assembly has been tampered with.
|
|
|
|
|
If all you have is a digital signature produced by some public key, and you don't have any idea where that public key really came from, the signature isn't worth much.
There are, however, a some ways in which signatures can be worth something:
-1- If you have two signatures, both produced using the same public key, you can tell both signatures were produced by a person or persons with access to the same private key.
-2- If you have received a copy of a person's public key via some reliable channel, or even if you have a good cryptographic hash of the key, then you can confirm that a document signed using that public key was indeed signed using the person's private key.
-3- There exist a number of entities which will sign a certificate containing a public key and statement of identity; these companies make their living from the trust other people place in their certificates, so if someone asks for a certificate that says "Microsoft" the certificate authority will confirm that the person requesting the certificate has authority to act on Microsoft's behalf.
Most computers have a list of trusted root certificate authorities and their public keys. A full digital certificate might contain the following:
-a- A digitially signed affirmation by root signature authority that a particular public key from Bob's Certificate House is valid.
-b- A statement signed by Bob's Certificate House indicating that a particular key belongs to Acme Software.
-c- A statement signed by Acme Software indicating that a particular key may be used to validate its Whizbang products.
-d- A statement signed with the Whizbang products key indicating that a particular piece of software is valid.
Things are a little more complicated than that, to allow for the possibility of signature revocation, but the idea is that there is a chain of trust so that the root-level signature authorities don't have to validate every single piece of software that's supposed to be signed. If all the entities in the chain can be trusted (both to avoid signing anything they shouldn't, and to keep their key secure) then the final signature should be trusted. If any entity is dubious, so is the signature.
|
|
|
|
|
thanks man,
what about the delayed signing
i know why do we use it , (to keep our private key safe till we launch the final project)
Delayed signing stands for signing with only a "Public Key" , till we're done with the development then we "Actually sign it with the private key"
that's what i've red in lots of articles and msdn .
And that's what most confused me , because private key can never be exported , plus , the hash is already encrypted with the public key , hence , the delayed signing (with public key only)suppose to be sufficient
or , what do they mean by Actually sign it??
What do you think ??
|
|
|
|
|
I've not actually dealt with projects that required a formal signing procedure, but I believe the normal development-cycle approach is to have an internally-generated key which has fairly loose controls on it (not publicized, but freely available to everyone in the department), and configure all of the machines that will be used for development to accept it as a root-level key. Thus, all machines which are configured to accept that key will regard any assemblies signed with it as genuine; keys which have not been so configured will regard such assemblies as dubious.
|
|
|
|
|
Signing with strong name just ensures that your assmebly has not been tampered with after it has been deployed as CLR validates strong name while loading the assembly. But you can not trust the operations done by that code. Strong names are secure as long private key with which assembly was signed is kept secured.
When you sign the assembly with private key what is does is it encrypts hash of the assembly and embeds it with assembly alongwith public key. When a calling assembly invokes it, it first decrypts the hash with public key, then recomputs the hash from dll and compares it with decrypted has. If both match, then only assembly is loaded, else it wont be loaded.
Ravindra Sadaphule
MCSD.NET
|
|
|
|
|
Consider,
Dim t As TextBox
t = New TextBox
t.Name = "t_1"
Me.Controls.Add(t)
>The above code creates an object of a textbox(class) with name=t_1
Now I add a textbox(name=TextBox2) to the form. Now, can I create another instance of TextBox2?
To achieve this I tried the following...
Dim t2 As TextBox
t2 = New TextBox
t2 = TextBox2
t2.Location = New Point(100, 100)
Me.Controls.Add(t2)
>The above code creates a textbox same as TextBox2 in location (100,100). But now TextBox2 has vanished from its original location.
...any suggestions?
Eagerly awaiting your reply...
|
|
|
|
|
Kent Pawar wrote: Now, can I create another instance of TextBox2?
You create instances of a class. TextBox2 is an object, and assigning t2 to TextBox2 makes both of them refer to the same TextBox instance. If you want to create another instance of TextBox with the same properties as TextBox2, you'll have to find a way to Clone[^] it. If you are only interested in a specific set of properties, you can do
Dim t2 As TextBox
t2 = New TextBox
t2.Text = TextBox2.Text
t2.Location = TextBox2.Location
...
...
|
|
|
|
|
Thanks.. 
I later wanted to create multiple copies of a group of objects;so I created a usercontrol(class) of these objects and created objects of it.
|
|
|
|
|
Hi everyone ,
could anyone tell me what happens when i Add reference
from a dll to my project ? does it only add switch to csc.exe compiler or more than that?
do my referenced dll's list phyisically reside in some project file(s)?
|
|
|
|
|
Visual Studio adds an entry to the .csproj file. The referenced assembly becomes a dependency to the project, so the next time you build the project, it builds the dependencies first, copies the assemblies locally and then builds the current project, providing the list of referenced assemblies to csc.exe via the /r switch.
|
|
|
|
|
thanks man , your answer hits the spot
|
|
|
|
|
Technically, Visual Studio doesn't use CSC.exe, but yes, the main thing add reference does is add that dll to the what gets compiled.
It also allows Visual Studio to provide intellisence for members of that assembly.
|
|
|
|
|
|
PIEBALDconsult wrote: Visual Studio doesn't use CSC.exe,
Surely you meant "doesn't directly use"? MSBuild will have to use the compiler one way or the other.
|
|
|
|
|
I expect CSC and MSBUILD call the same classes and methods, but neither calls the other.
|
|
|
|
|
Visual Studio does indeed use CSC (and LC). You can see this in your Build Output panel.
|
|
|
|
|
I can see it even more clearly by renaming CSC and trying to build in VS (2005 and 2008 anyway).
So where did I hear that it doesn't?
Oh well, my bad.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
