|
Please try tlbimp on the dll and see what error you are getting.
tlbimp 'dllname'
|
|
|
|
|
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.
Any ideas?
|
|
|
|
|
Found the problem. Working fine now.
|
|
|
|
|
Hi guys :->
Anyone knows how we create a standalone manifest file? A file which only contains metadata not any IL code.
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
|
Hi,
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.
Any idea why this could be happening?
Thanks in advance.
Regards,
Edwin.
|
|
|
|
|
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.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi Dave,
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?
Thank you! 
|
|
|
|
|
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.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Ok, thank you!
Now i understand it a lot better!
I guess i've to keep Working Set & Private Bytes as low as possible...
Thanks Again!
PS: Does anyone else knows what Virtual Size means 
|
|
|
|
|
Thank you Dave. That was very useful information!
-Edwin.
|
|
|
|
|
Hey guys,
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?
-Waffleman
================================
Freiheit ist von Gott, Freiheiten vom Teufel.
|
|
|
|
|
Dear Waffleman,
Option 1:
Try using Process.Execute(...) from your Custom Action in order to execute the third party installation, if it does not violate your installation sequence.
Option 2:
Get into the msi database by using some free tools such as Orka (from microsoft). Please search for it in msdn for more info.
tth.
-Edwin.
|
|
|
|
|
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.
Robert
|
|
|
|
|
well, I have a .net assembly(FooAssembly) with a class(FooClass).
there is a delegate(event) inside FooClass and related eventArgs class.
I need to use this assembly in VB6, so I first create an interface for the FooClass, but for the delegate, I have no idea how to realize it.
anybody has any idea
Regards,
unruledboy@hotmail.com
|
|
|
|
|
Hello,
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?
Please help,
Eric
|
|
|
|
|
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 .
Amey
|
|
|
|
|
|
|
The best book is Inside C# second edition by Tom Archer ( who is a CP regular and now an MVP ). It goes into the sort of detail you're looking for, it's my number one C# reference.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I would second this suggestion, it's a great book!
|
|
|
|
|
Thnx guys , Ur help means a lot to me !
|
|
|
|
|
Jesse Liberty - Programming C# is pretty good at covering the ins and outs of the C# language pretty concisely. It's now in its 4th edition.
Kevin
|
|
|
|
|
I agree on this as well. It's published by O'Reilly. I also liked "Programming ASP.NET" by Jesse Liberty & Dan Hurwitz (O'Reilly as well). "ASP.NET 1.1 Insider Solutions" isn't so bad either - a bunch of tips and tricks. It's by Alex Homer, Dan Kent, Dave Sussman, and Dan Wahlin (published by SAMS).
Dirk Watkins
|
|
|
|
|
drkwtkns wrote:
I also liked "Programming ASP.NET" by Jesse Liberty & Dan Hurwitz (O'Reilly as well).
Yes, I have that too.
Kevin
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
