|
James T. Johnson wrote:
there are several known bugs that occur when building dlls/exes that are larger than 64K
 
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Martin Häsemeyer wrote:
The bug relates to VS.NET locking the dll after building. There are a couple things that trigger it.
First you need to tell it to build into a different directory than the default; then you need to have Copy Local set to false in one or more projects that reference that assembly.
Someone from MS commented on it recently on one of the DOTNET lists, I don't remember what he said about it though.
James
- out of order -
|
|
|
|
|
James T. Johnson wrote:
The bug relates to VS.NET locking the dll after building. There are a couple things that trigger it.
First you need to tell it to build into a different directory than the default; then you need to have Copy Local set to false in one or more projects that reference that assembly.
Someone from MS commented on it recently on one of the DOTNET lists, I don't remember what he said about it though.
Well, OK! If it is such an effort to create the buggy behaviour it won't touch a lazy man like me 
Cheers
and thanks
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Is there a way to create a new event that occurs AFTER the check state of an item changes?
Ingram Leedy
You can't depend on your eyes when your imagination is out of focus.
--Mark Twain
|
|
|
|
|
Just two suggestions though I don't know if they'll work:
1) You could override the mouse click event, and look wether the check state changed
2) You could override WndProc and try to intercept the corresponding Windows message, if it exists (might be a WM_NOTIFY with some code you can find in MSDN for the ListView common control)
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Martin,
That sounds like something to explore. If I use ItemCheck and then change the check state of the item inside the event handler, then it fires ItemCheck again, and we go into a circle. I suppose I could set some toggle bit, but that seems like a hack.
It seems like in other controls, that AfterEvent handles, seem to ignore changes relating to that event. Is my thinking correct? Am wondering how they do it?
-- Ingram
Ingram Leedy
You can't depend on your eyes when your imagination is out of focus.
--Mark Twain
|
|
|
|
|
Ingram Leedy wrote:
It seems like in other controls, that AfterEvent handles, seem to ignore changes relating to that event. Is my thinking correct? Am wondering how they do it?
 Maybe that's the case. But I don't know how this would be possible. Maybe for these controls only if the selection is changed via user input (mouse keyboard) the event get's fired and not if you change the property programmatically (event handler tied to the message an not the property). But if that isn't the case I don't think it would be possible to change the check state without goin into a loop, unless you override the property, but dunno if that's possible or even helps.
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
You might be right, perhaps these events get fired based on something else?
It seem like what I am trying to accomplish would be a common thing. I want to put custom checkbox images in the listview. I've done this with TreeView using Genghis CustomTreeView. (In that, I use treeView1_AfterCheck which works fine if I change image states programmatically) http://www.genghisgroup.com[^]
ListView however is giving me greef. Here is a snippet of code as a sample that increments the image of the checkbox, that once I change the image for the checkbox it fires a new event.
I also wrote a custom state listview that sets the images using an Interop
by sending the state changes directly using Win32. But it causes the event to fire just like the example code.
private void listView1_ItemCheck(object sender, System.Windows.Forms.ItemCheckEventArgs e)
{
listView1.BeginUpdate();
int itemcheck2 = listView1.Items[e.Index].StateImageIndex;
Debug.WriteLine("Check image #: " + itemcheck2.ToString());
listView1.Items[e.Index].StateImageIndex = itemcheck2 + 1;
listView1.EndUpdate();
}
Thanks -- Perhaps someone has dealt with this.
Ingram Leedy
You can't depend on your eyes when your imagination is out of focus.
--Mark Twain
|
|
|
|
|
I'm working on a wrapper to simplify the usage of the .Net cryptography classes, and have a few questions
I need answers for before I can use/publish it:
1) I am currently creating the key byte array for each alg by hashing a text password with UTF8 encoding,
is this the best practice for generating the key?
I understand that a unique IV should be used for each encryption, so that blocks of identical data are
different even with the same key. I am currently storing the IV bytes at the beginning of the encrypted
file, and reading them back when decrypting.
2) Does the IV being exposed like this weaken the crypto?
3) Should I be encrypting the IV with the key and a known IV before storing it in the encrypted file?
|
|
|
|
|
Wow, I guess *no-one* knows.. *sniff* 
|
|
|
|
|
I have a .NET application and I'd like to distibute it in 2 forms:
1. As is.
2. Compiled to run on a Windows systems which may not have the .NET framework.
Is there a way to get a native application from a collection of assemblies? I looked into the ngen.exe program, but this appears to only pre-compile assemblies into an internal cache.
|
|
|
|
|
Somewhere on this forum, someone was asking about Obfuscators and wanted an opinion about something from Salamander software (IIRC) which turned .NET apps into native code. Find the link and see whether it still requires the .NET framework installed.
James
- out of order -
|
|
|
|
|
James T. Johnson wrote:
Somewhere on this forum, someone was asking about Obfuscators and wanted an opinion about something from Salamander software (IIRC) which turned .NET apps into native code. Find the link and see whether it still requires the .NET framework installed.
IIRC, Salamander is only a super-NGEN, you still need the .NET framework
Your incessant rantings indicate you have a brain the size of a pea, and the mental capacity of a bag of hammers. - John Simmons
|
|
|
|
|
jstonge wrote:
2. Compiled to run on a Windows systems which may not have the .NET framework.
This is impossible IMHO. You will always need your assembly (because of the metadata) and the framework (as the class library and to interpret it) even if you precompile your assembly (with NGEN for example).
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
And eventually all PC's will have the .NET framework pre-installed , just like all the VB/C++ runtimes. Its not all that different and could possibly decrease the size of an application if the application is very big.
I wonder if it is possible the make a cutdown version of the .NET framework like as in Java, where only needed assemblies are required and the "WebStart" it. 
"I dont have a life, I have a program."
|
|
|
|
|
This is a huge problem with .NET
If you're a small company and generally don't distribute your apps on CD, .NET is severly limiting your potential market.
I've managed to compile C++ 6.0 using Studio.NET and the final exe does not require the 22MB framework but I have been unsuccessful with VB.net
I agree that EVENTUALLY, everyone will have the framework installed, but untill then, would you download a 22.1MB application or a 100Kb application?
Rick Eastes.
http://www.eastes.net
|
|
|
|
|
I'd like to design a distributed system such that:
* Clients simply connect to the server, and wait for a callback. This is not an anync result, they are simply waiting for the server to call them. Think of this as the server firing an event for the client to respond to.
* Server does its thing. At times, it will need to perform a callback to a particular client.
I've seen examples on how to use delegates and shim classes to deal with my first requirement. But nothing I've seen suggests I can acomplish my second requirement. How can the server be aware of all the clients connected to it, and perform a callback on a particular one?
|
|
|
|
|
|
I have a .NET service that needs access to a network share. When the service is logged in as 'local system' it cannot access the network share. When the service is logged in as any domain user it can access the network share.
Is there a way in code, to allow access to the network share when logged in as 'local system'?
Thanks - Joel
|
|
|
|
|
By default the Local System account has no network credentials. I don't know if you can change this or not. The recommended solution is to create a user with only the permissions you need.
James
- out of order -
|
|
|
|
|
change the account it executes as...
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
 What i know is COM will no longer be used in .NET. Although we can create COM components but in future developments COM is not the standard way of create reusable components. is it so?
@ish@
|
|
|
|
|
Yes, I think this will be so in the long run. But it will take several years I think .NET itself still uses COM+ for some parts but I get the impression that eventually it will all be replaced by native .NET. I suspect Windows itself and perhaps some MS apps. wil still use COM internally but application developers will write .NET components for new stuff.
Kevin
|
|
|
|
|
Kevin McFarlane wrote:
I get the impression that eventually it will all be replaced by native .NET
If you want to use the shell, you have to use the COM shell interfaces. .NET classes exposing shell features do exactly that for us, but in the end if the COM shell objects are badly installed, or badly registered, it won't work, regardless of the .NET virtual machine and classes.
Kevin McFarlane wrote:
I suspect Windows itself and perhaps some MS apps.
Again no. The entire operating system is based on COM. What we developers do is use the features provided by these COM objects. So in the end, we need at least a COM bridge. That's P/Invoke. Because of that, not only the underlying COM is not going to vanish but also, quite the contrary, people are using platform invoke with C# to solve their problems. In the marketing brochures, MS never talks about that hybrid .NET code made of simple C# (or VB.NET, ...) code, plus all the application logic done with platform invoke. I can't figure out what is "native .NET" when it comes to real world problems, really.
What is going to change through the years ?
- probably the classes provided to us will have more "business objects", hopefully.
- .NET will be more than ever out of developers' control, unlike MFC dlls for instance. The ability to run your .NET app on someone else machine will probably rely mostly on the actual target .NET runtime to accept your IL code (based on some .NET-compliance certification steps, or whatever MS might think about it along the way...).
|
|
|
|
|
Thanks. Very informative.
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
