Hmmm, I've tried that, but like I said, I don't really have that usable of an interop assembly... It only gives me Core::IManager, just the interface... Do I have to implement that interface, or write a wrapper for that? There are no class objects for me to instantiate... Some sites talk about coclasses, but I have none defined in my IDL file, and I'm not really sure what I'm doing as far as that... haha, am I just doing this wrong?
Hmm, I tried that, but it can't find any IManagerClass class... I know that when you use tlbimp or import a DLL or type library through .NETs Add Reference thing, in the managed assembly there should be 2 public classes;
but only IManager is there when I run the MSIL Disassembler...
Maybe my IDL file is wrong? Or should I just give up with trying to import the type library and figure out the hard way how to write a COM class wrapper?
We have a project that was just converted form 6.0 to .NET, which, in turn, generated a ton of errors. Most of them we're getting worked out, but this one seems to be really stubborn. It doesn't happen in all of the projects, just some of them; we can't seem to figure out why. Unfortunately, we're all relatively new to the .NET enviroment, so we're learning as we go.
The include statements have the correct syntax: #include "somefile.h" and some of the .h files are in the project (although others are not). We did try including the .h files into the whatever project was generating this error, but it didn't help.
We've checked the enviroment variables and they're fine; exactly what they should be. We know that we can include the entire path to correct this, but there are hundreds of files in dozens of projects that may need to be changed; we're trying to find an easier way to correct this error.
I am working on a Windows based C# application, running on XP on Framework 1.1. The main UI of my application contains a Tab Control, and on a particular action (such as a button click) a module is opened in a Tab Page in the Tab Control.
My question relates the following strange observation: When I execute my application (in Debug mode) and check for the memory status in Task Manager, I notice that every time I open a module, a large amount of memory (about 20 MB) is created. But when I close the module only a small amount of memory (about 2 MB) is released. I have checked in two different Memory Profilers to ensure that all the objects are garbage collected properly; both the profilers report complete release of managed memory. One of the profiler actually reports only 2MB as allocated on the managed heap when my module is opened and the same amount as reclaimed when closed.
When I perform the above operation of opening and closing of the module contineously, Task manager shows that each time there is an increase of about 1 MB in memory size.
I am using a COM object, which is being released with the call Marshal.ReleaseComObject(). I also use a Win API call from a "static extern" declaration.
Edwin Anand wrote: and check for the memory status in Task Manager
First, do not ever do this with Task Manager. It will never give you how much memory your managed .NET application is actually using. Use Performance Monitor and the .NET Framework counters to do this.
Here's the simplified explanation:
What you're seeing in Task Manager is how much memory has been reserved for your applications MANAGED memory heap, not how much your app is using! The Managed Heap is a nice size block of memory, reserved for your applications use, created out a block of unmanaged memory. There's a reason why the .NET Framework runtime environment is called a virtual machine, just like Java's runtime environment.
The .NET Framework memory manager will set aside a block of unmanaged memory (what you're seeing in Task Manager) and create the Managed memory heaps in it. When you application creates an object, it's created in either the Small Object Heap or the Large Object Heap, depending on the objects initial size. Since this object has been created inside the Managed Heap, there's no effect on what you see in Task Manager since it only looks at unmanaged memory. When the object goes out of scope, the memory gets released back to the Managed Heap, not the unmanaged.
Now, the numbers you see in Task Manager DO change during your applications execution. Why? There's a couple of reasons.
The .NET Memory Manager likes to keep a cushion so the next time you allocate an object, you don't have to wait for the memory manager to grab another block of unmanaged memory and add it to the managed heap, then allocate your object in it.
But, the memory manager also has to balance what it allocates against what Windows wants for other buffers and processes. The memory manager, when it thinks there is too much unmanaged memory allocated to your app, will release managed memory back to the unmanaged heaps. This will happen when you deallocate an object or when your applications data gets swapped to disk and back to RAM.
To see a little demo of this, try starting your application and watch what happens in Task Manager. You'll start out with a good size chunk of memory (roughly 15-20 Meg on startup). Now minimize your application and watch what happens in Task Manager. It drops considerably because your app just got swapped to disk. Restore your app so you can see it again and your app's memory consumption will increase, but not as high as when you started your app. Since your application didn't need some data and free space, the memory was either not swapped back to RAM or was released back to the unmanaged pool.
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
It seems that you know a lot about memory stuff (Oh yeah you're so smart ).
I use Process Explorer instead of the Task Manager.
And i see 3 columns: Working Set, Virtual Size and Private Bytes.
Do you know what these memory-items mean?
I think Private Bytes is the Managed Heap you're talking about, but i'm not really sure.
And do you know which of the three is important to keep as low as possible?
Working set is the number of pages of that process that are currently in physical memory. I'm not sure about virtual size, private bytes is the number of bytes that can't be shared with other processes. Typically, code can be shared with other processes, but because .NET using JIT compilation, private bytes tend to be on the higher side for .NET apps.
I've got a VS.NET setup-project that I recently made for a VB.NET program that I wrote. The program requires some 3rd party files that another setup installs. I use a custom action to launch the third party setup. Here is my problem: After the 3rd party setup finishes, it asks the user if s/he would like to restart their computer now or later. If the user decides to restart immediately, the shortcuts and menu links of the main program never get installed because the restart stops the original setup.
Is there any way to launch the 3rd party setup after my setup? Or does anyone have any other ideas?
Freiheit ist von Gott, Freiheiten vom Teufel.
The fact that you can even launch the setup from a VS.NET setup means that it was not created using Windows Installer, because Windows Installer does not allow a second instance of msiexec to be launched.
This precludes the option to edit the 3rd party setup with Orca.
You still have a couple of other possibilities:
1) Determine what was used to create the 3rd party install (ex. Wise, Installshield, etc) and see if the 3rd party setup supports execution with a commandline switch that suppresses the reboot option. Many setups support this feature, but not all. If your setup supports a switch to suppress the reboot, you simply modify your custom action commandline.
This option presents a certain problem however. A lot of setups are authored to automatically offer a reboot option, even though a reboot may not be required for the software to run. In other cases, a reboot may be required only on certain OS versions or only if certain files were in use. It is pretty much impossible to know (or test under all possible scenarios) if the reboot is actually required or if it was merely authored into the package.
So basically you are left iun a situation where the only assumption you can make is that the reboot is required, but you have now suppressed this option, and the user may try to use the software and think the setup failed. So you should probably author your MSI to force a reboot to be safe. This is not something you can do in the VS IDE so you will have to download Orca and the Windows Installer SDK and figure out how to modify your VS.NET setup to force a reboot at the end.
This is not a trivial task, unfortunately.
2) A second option, which in my opinion is probably easier, but requires you to be able to at least manage some level of C++ programming, is to modify the bootstrapper EXE.
VS.NET includes a standard bootstrapper called setup.exe. This is a program that usually first checks to see if the Net framework is installed. If so it launches your msi and terminates. If not, it first runs the dotnetfx.exe to install the Net Farmework, then launches your msi and terminates.
You can download the bootstrapper exe source code from the MSDN site, and modify it to do anything you want.
In this case you would want to modify the bootstrapper to launch your msi, but NOT terminate, wait for a successful return code from the msi install, and then launch your 3rd party install and terminate. This will result in your 3rd party install being the last operation required in your setup sequence, and you can allow the user to reboot because all other setups will have already completed.
I suggest you try the second option if you can manage the C++ code. It's not particularly difficult, if you have at least some very basic experience with C++, or even just a good reference text.
After spending eight hours on google, tryin' to find it I came to the conclusion that it only is possible using VBScript. BUT I really really want to realise it in C# or VB.net and it should be compatible with Server 2000.
Does anyone ever accomplished it in .NET ? Maybe with the help of 3rd party DLL?
Hi Guys ,
I'm a s/w engineer working in Honeywell . I am a fresher and have some experience working in vc++,mfc,COM/DCOM and other microsoft technologies. I also have read some books on .NET and C# , but I found most of them (all) not of much help (I would rather use MSDN ). Now all the new development tht I would be doing would be in .NET . So can anyone suggest a good book in .NET and C# which would go into detail and would be like a complete bible instead of jst explaining the APIs .
Any help would be appreciated .