|
Yep I thought at that option too earlier and it works...
I solved my problem with indexes and substrings.
Thanks
|
|
|
|
|
You're welcome 
Kristian Sixhoej
|
|
|
|
|
hi ipstefan,
my sugession is read contents of file sequentially and check whether the character u r reading is ", it it is then take all next characters untill next " apprears so u can get each character between "". From these chars u can make a string by using + operator and later it can be pasted where u want.
Or as u mentioned myString.find() method, i hope find method is custom method not in framework. Instead, u can use following method of class String.
String myString = "abcd";
String cutString = myString.Substring(0,3);
the value of cutString will be 'abc' . Try to use this method. Ok..
Hope it will help u.
|
|
|
|
|
Dear all,
I am working on C# project, which need to digital sign on all data (string DataType). I have .pfx (X509) file already (contain public key + private key). Is there anyway to pass the private key + public key in .pfx file to DSA, to create digital signature ?
Below is the code in JAVA, which I think use DSA in C# may create the digital sign exactly this java code.
Many thank if you can help.
//---------------------- JAVA DIGITAL SIGN CODE ---------------------
private static void readPrivateKeyAsClassPath() {
try {
// Read key
InputStream fis = SignatureDegist.class.getResourceAsStream("/"
+ keyFile);
ObjectInputStream ois = new ObjectInputStream(fis);
priv = (PrivateKey) ois.readObject();
ois.close();
} catch (Exception e) {
}
}
/**
* @param filename
* @throws FileNotFoundException
* @throws IOException
* @throws ClassNotFoundException
*/
private static void readKeysPrivateKey(String filename)
throws FileNotFoundException, IOException, ClassNotFoundException {
if (priv == null) {
setKeyName(filename);
readPrivateKeyAsClassPath();
}
}
private static byte[] sign(InputStream reader, String sigAlg)
throws Exception {
Properties pro = new Properties();
pro.load(SignatureDegist.class.getResourceAsStream(CONFIG_KEY_FILE_LOCATION));
if (priv == null) {
readKeysPrivateKey(pro.getProperty("filename"));
}
Signature sig = Signature.getInstance(sigAlg);
sig.initSign(priv);
byte[] dataBytes = new byte[1024];
int nread = reader.read(dataBytes);
while (nread > 0) {
sig.update(dataBytes, 0, nread);
nread = reader.read(dataBytes);
}
;
return sig.sign();
}
private static byte[] sign(String datafile, String sigAlg) throws Exception {
return sign(new ByteArrayInputStream(datafile.getBytes()), sigAlg);
}
public static void main(String[] unused) throws Exception {
// Generate a key-pair
String accountIdSource = "123100003456";
String accountIdDest = "456100014123";
long value = 100;
String desc = "transfer";
String contactID = "NHK-XJ";
String typeId = "00";
StringBuffer buffer = new StringBuffer();
buffer.append(accountIdSource);
buffer.append(accountIdDest);
buffer.append(value);
buffer.append(desc);
buffer.append(contactID);
buffer.append(typeId);
byte[] degist = sign(buffer.toString(), "SHAwithDSA");
System.out.println("Signature degist :: " + degist);
System.out.println("Signature degist :: " + new String(degist));
Base64 decoder = new Base64();
System.out.println("Signature degist :: " + new String(decoder.encode(degist)));
System.out.println("Signature degist :: " + new String(decoder.encode(new String(decoder.encode(degist)).getBytes())));
|
|
|
|
|
Hello,
a 3rd party supplier informs me their components are compiled for "ANY CPU", so they'll run x86 or x64 based on the platform to which they're deployed. This confuses me a bit; I had thought a select choice of x64 compilation would ensure the best performance, which is why so many companies these days deliver product-installers for both x86 and x64. But if I'm to take his word for good measure, there's no need (at least .net-wise) to ever compile to a specific CPU architecture, as the "ANY CPU" option will always ensure the assemblies run as fast as possible, given the host CPU?
Hope someone might be able to clarify on this,
thanks in advance,
Morten
|
|
|
|
|
The Any CPU option is not optimised for a specific processor. It will give you good general all round performance that works across any of the target processors. If you absolutely must have all the performance you want then target the appropriate processor.
[ADDITIONAL]
First Addition::
There seems to be a lot of confusion about this. MSDN says one thing. The C# compiler command line help says another.
Second Addition:
See Guffa's post as he links to an article that explains exactly what is happening, and contradicts the MSDN article I used as the source of my original answer.
[/ADDITIONAL]
modified on Friday, January 9, 2009 1:24 PM
|
|
|
|
|
Hello Colin,
this was also my impression. Thanks a lot for clearing this up for me.
best,
Morten
|
|
|
|
|
harleydk wrote: Hello Colin,
this was also my impression. Thanks a lot for clearing this up for me.
Then your impression was also wrong.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Colin Angus Mackay wrote: It will give you good general all round performance that works across any of the target processors. If you absolutely must have all the performance you want then target the appropriate processor.
That is not correct. The IL code generated is the same regardless of which CPU target you specify.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
I saw that one. It doesn't go ino any depth, and I don't think that it's correct. Have a look at this, for example:
Visual Studio .NET Platform Target Explained[^]
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
The IL code in your assembly isn't specific to any processor at all. Regardless of what CPU target you choose, the IL code could still be used on any processor. The CPU target is simply information that the code should only be allowed to be used on a specific type of CPU.
You can use the CPU target for example to specify that your assembly only can be used in x86 mode as you are calling methods in an unmanaged x86-dll.
It's the JIT compiler that creates the machine code from the IL code when your assembly is loaded. It can create different code depending on the actual processor that will run the code, so that it will take advantage of the capabilities or that specific processor.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: The IL code in your assembly isn't specific to any processor at all.
That was also my thought until the OP asked the question and it got me thinking. I then looked at MSDN and this article suggests (although not explicitly to do with the IL output) otherwise: http://msdn.microsoft.com/en-us/library/5b4eyb0k.aspx[^]
|
|
|
|
|
c:\> csc /?
...
/platform:<string>
Limit which platforms this code can run on: x86, Itanium, x64, or anycpu. The default is anycpu.
</string>
It has nothing to do with optimization.
As usual, MSDN is wrong.
|
|
|
|
|
nice one:[^]
- the title is "How to: Optimize an Application for a Specific CPU Type"
- for C# the page says "Choose a CPU type from the Platform target list. The options are ..."
- and Guffa rightfully says "The IL code in your assembly isn't specific to any processor at all"
So the page not only fails to tell you how to decide on the right platform, it also leads you to believe that by choosing you would be optimizing the application. The whole page is crap 
|
|
|
|
|
Yes, very confusing. It even got me and I should have known better. 
|
|
|
|
|
harleydk wrote: I had thought a select choice of x64 compilation would ensure the best performance
Wrong. Selecting x64 does NOT give the best performance. This only forces the code to work on a 64-bit processor using the 64-bit .NET Framework. This also give you coding options that are specific to 64-bit. Performance really has nothing to do with it.
|
|
|
|
|
Thank you, everyone, for your insight on this issue.
Can I ask you, now, how I should go about optimizing my code for x64 processors? Any links you would recommend would be much appreciated.
Many thanks,
Morten
|
|
|
|
|
Hello.
I am new development of dvd player. Any good material to start with. and Some sample codes too.
Thanks.
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
- Bjarne Stroustrup
|
|
|
|
|
Wow are you in over your head.
|
|
|
|
|
I am sorry, my bad.
What I meant was:
I am new to the software development of dvd player for windows. I need some basic tutorials and resources to start with.
Thanks.
|
|
|
|
|
|
Hello guys,
As I said in the subject line, the goal is to deploy a console application to another machine without Visual studio 2008 installed on that machine. It does have 2005 installed on it though.
Questions:
1- Do I need to install the Framework 3.5 on this machine for the console app to work?
2- I'm not sure what steps should be taken to accomplish this deployment (provided that I install the framework). In other words the Bin directory of this folder contains consoleApp.vsHost.exe.manifest (type: manifest file), consoleApp.vsHost (type: Application), ConsoleApp (type: Application).
3- Should I just copy over these files and a few other DLLs that are being referenced from this console application over to the other machine and be able to run the executible from there?
4- when I right click, and look at the properties of the console application project, i see quite a few options (in VS 2008) Is the publish option relavent to this deployment? Especially the publish location and install Mode and settings options?
Thank you all so much in advance for your help
Tina
|
|
|
|
|
1 - Yes, if it uses 3.5
2 - See 3
3 - You can, and I do it that way, but it depends on other factors
4 - That's another way to do it, which maybe I should do, but don't
|
|
|
|
|
Tina P wrote: 1- Do I need to install the Framework 3.5 on this machine for the console app to work?
Yes
Tina P wrote: 2- I'm not sure what steps should be taken to accomplish this deployment (provided that I install the framework). In other words the Bin directory of this folder contains consoleApp.vsHost.exe.manifest (type: manifest file), consoleApp.vsHost (type: Application), ConsoleApp (type: Application).
Just Take all files of Bin folder to destination machine
Tina P wrote: 3- Should I just copy over these files and a few other DLLs that are being referenced from this console application over to the other machine and be able to run the executible from there?
You do not require source files on client computer
Tina P wrote: 4- when I right click, and look at the properties of the console application project, i see quite a few options (in VS 2008) Is the publish option relavent to this deployment? Especially the publish location and install Mode and settings options?
I don't know
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
