|
Hi!
Thanks for reply, i just solved my problem with your mentioned method. I am not able to populate 100000 records in 4 seconds, as you mentioned, it is taking approximately 10 seconds, but stil it is better than 1 minute and fulfils my requirment..
Thanks again...
Regards,
Affan Ahmad Toor
|
|
|
|
|
Affan Toor wrote: I am not able to populate 100000 records in 4 seconds, as you mentioned, it is taking approximately 10 seconds,
Noone ever said XML was fast. Storing 100000 records in an XML file is not a good idea. XML was meant to be a transport, not a database. It only has the look and feel of a database table.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Hello all, we are writing a server that comunicates with clients using .Net remoting but we have a couple of problems:
in order to keep separated the implementation of the remotable object we create that object on the server. That object exposes a GetConnection object that returns a new object for each request, this way we can have a dedicate object for each client. Is this a correct way of achieving this?
In addition, we need a way to listen the connection status of each object (that is, if a client losts the connection, we can close the thred).
Can someone help me? Thank you all!
Alessandro
|
|
|
|
|
What was the logic behind the decision for the Release build of a C# program to be totally decompilable even down to the variable names? It seems an incredible design decision to me.
|
|
|
|
|
It's not really an incredible decision. How would you expect reflection to work? How about JIT compilation? Remember, that .NET generates IL code and you see why it works the way it does.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
That's all well and good but why include the original variable names? Why not produce a compact form with minimal identifiers? MS are anti-GPL because you have to give out your source code, and here they are promoting a language which effectively distributes your source code on a plate!
|
|
|
|
|
Original variable names are still required for reflection to work, Additionally, all (non-private/internal) entity names are required for the way the CLR finds external references. The one thing that could be "removed" are scope-local variables, but that won#t help a lot, andobfuscatorsa can do this.
I fully understand your concern, I need to keep this in mind permanently when deciding which technology for which product. But that's a tradeoff that in most cases makes sense.
There are two main ways to deal with code to protect:
* use an obfuscator
* move critical code to an unmanaged binary
* Reflection.Emit
All are not "complete": obfuscators seem a delicate balance between making the code unreadable and breaking it. External binaries, beisdes the old "find that DLL" problem, would still isolate the critical part and make reverse engineering the easier. Reflection.Emit could be used as addiitonal "obfuscation of ideas", but doesn't protect the code from being copypasted.
IIRC upcoming Authenticode features are supposed to provide a new mechanism that gives you control over who sees what. (I am not sure though, how well it is received or protects, as it sounds to much like DRM)
But keep in mind that every binary is reverse engineerable, it's just a quesiton of skill and patience.
|
|
|
|
|
There's a number of reasons for this. At the core, the fact is that most people are targetting markets that do not contain people likely to decompile code. Having your code compile on the target machine opens the door to things like a version of the framework that optimises for new processors, such as dual cores or 64 bit. It also means that in theory the framework can target multiple architectures.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: It also means that in theory the framework can target multiple architectures.
What do you mean in theory? What about Mono?  Doesn't that run on most Linux systems which run on most processors?
|
|
|
|
|
Isn't Mono not allowed to impliment the Windows.Forms classes ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
From what I understand they are allowed but things at the moment are so tied down to Microsoft's way of things that they implemented stuff on GTK because a it was easier and b provided more flexibility (GTK was more established on different platforms and had more flexibility I think). I've got a feeling that they may have simply mapped the critical Windows.Forms to the GTK namespace.
You can from what I remember of my experimentations run most Windows.Forms apps on Mono without any adjustment but there are a few classes etc which are deeply tied into MSs way of things that they don't run. (Yet again) from what I remember the comments were that yes there are some problems with simply copying and pasting code across but there are some quite straightforward workarounds which will work in both Mono & MSs implementation so as long as you know of these before hand you should be OK.
Of couse most people writing for Mono use the GTK etc implementations because they're more used to coding to those in C++ etc and they're stuck in their ways.
But as far as I know there isn't a legal reason why Mono can't implement the Windows.Forms classes.
|
|
|
|
|
I understand that, but for a release build to contain the original variable names is just daft. Why not do a compile-time replacement of the names with the shortest possible names to at least obfuscate your code and make the IL version as short as possible?
|
|
|
|
|
to create work for people writing obsfucators, of course.
Decompilation is very useful, for example, if you need to see what the framework is doing. You don't get the source like you did for MFC, but with a decompiler, you do.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: to create work for people writing obsfucators, of course.
Not only does it let you see what the framework is doing, it also lets your customers see what you are doing. Suppose you are charging for the interface software to some proprietary hardware - with C# your customers can see exactly how the interface works and write their own for free. Goodbye revenue stream!
This has put me off using C# for any serious work that I will be sending to customers. I think I will be sticking with C++ and MFC for the foreseeable. 
|
|
|
|
|
Steve_Harris wrote: This has put me off using C# for any serious work that I will be sending to customers. I think I will be sticking with C++ and MFC for the foreseeable.
Why? Unless you are doing serious reflection, there are ways round this using tools like Obfuscators.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Why should I have to buy one just to protect my IP? If I compile a C++ program it is immediately pretty well protected.
|
|
|
|
|
Steve_Harris wrote: Why should I have to buy one just to protect my IP? If I compile a C++ program it is immediately pretty well protected.
But not bulletproof. While it is protected better, it still isn't totally foolproof. All code is capable of being reversed.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Steve_Harris wrote: it also lets your customers see what you are doing
Sure, if you have the sort of customers who would be inclined to look.
Steve_Harris wrote: I think I will be sticking with C++ and MFC for the foreseeable
The obvious alternative is to write C++ DLLs that hide your proprietary stuff and call them from C#.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: The obvious alternative is to write C++ DLLs that hide your proprietary stuff and call them from C#.
What about C++/CLI? Isn't that managed and unmanaged code in the same assembly?
(Just curious...  )
-alwinus
|
|
|
|
|
C++/CLI is managed code, so it also can be decompiled. It can be a combo of both, but the unmanaged part is the only way to write stuff that can't be decompiled.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I have 2 binding lists (say A and B), i need to compare the contents of A to B to see if they conatin the same items.
How can i do this?
|
|
|
|
|
You will find good number of information on the following site
http://www.thescripts.com/forum/thread231103.html
Regards,
Jaiprakash M Bankolli
jaiprakash.bankolli@gmail.com
http://jaiprakash.blog.com/
|
|
|
|
|
hi,
I am saving some content in an XML file and and i am passign a XMl file name as a parameter to some function..
if i give normal file name it is creating a XML file.
but if I give some extra charcters like this in a file name &,",' it is giving error like below
"The & character,hexadecimal vale 0x26 can't be included i a filename"
is there any way to handle extra chracters.
pls help me.
-- modified at 5:22 Thursday 12th April, 2007
|
|
|
|
|
71 wrote: The & character,hexadecimal vale 0x26 can't be included i a filename"
The error is correct. Try to create a file with that name in the file system and you'll find it's a limitation of windows. In fact, that's a good way to get a list of characters you need to remove or not allow in your filenames.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Well, actually '&' is a legal character in a Windows filename.
Illegal characters are: '/', '\', ':', '*', '?', '"', '<', '>' and '|'.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
