|
Hi
I have recently upgraded from vs2003 - vs2005. I had made some changes to my application and i had simply sent our
customer an updated exe file. When they pasted the file into the installed directory and replaced the existing file
they got an error message appear
"The application has failed to start because the application configuration is incorrect. Re-installing the application may fix this problem"
So, i re-generated the deployment project in vs2005, and tried to run this. when this ran it came up with a warning (see below) and then prompted me to downloadload and install .net framework 2.0, i went through this process and completed the install and the install of my application. but when i went to run my application i got the "The application has failed to start because the ....." error again
has anyone come across this before ? or any ideas on whats wrong ?
Warning which appears when deployment program is run
MICROSOFT SOFTWARE SUPPLEMENTAL LICENSE TERMS
MICROSOFT .NET FRAMEWORK 2.0
MICROSOFT WINDOWS INSTALLER 2.0
MICROSOFT WINDOWS INSTALLER 3.1
Microsoft Corporation (or based on where you live, one of its affiliates) licenses this supplement to you. If you are licensed to use Microsoft Windows operating system software (the "software"), you may use this supplement. You may not use it if you do not have a license for the software. You may use a copy of this supplement with each validly licensed copy of the software.
The following license terms describe additional use terms for this supplement. These terms and the license terms for the software apply to your use of this supplement. If there is a conflict, these supplemental license terms apply.
By using this supplement, you accept these terms. If you do not accept them, do not use this supplement. If you comply with these license terms, you have the rights below.
1. SUPPORT SERVICES FOR SUPPLEMENT. Microsoft provides support services for this supplement as described at www.support.microsoft.com/common/international.aspx.
2. MICROSOFT .NET FRAMEWORK BENCHMARK TESTING. This supplement includes the .NET Framework component of the Windows operating systems (".NET Component"). You may conduct internal benchmark testing of the .NET Component. You may disclose the results of any benchmark test of the .NET Component, provided that you comply with the following terms: (1) you must disclose all the information necessary for replication of the tests, including complete and accurate details of your benchmark testing methodology, the test scripts/cases, tuning parameters applied, hardware and software platforms tested, the name and version number of any third party testing tool used to conduct the testing, and complete source code for the benchmark suite/harness that is developed by or for you and used to test both the .NET Component and the competing implementation(s); (2) you must disclose the date (s) that you conducted the benchmark tests, along with specific version information for all Microsoft software products tested, including the .NET Component; (3) your benchmark testing was performed using all performance tuning and best practice guidance set forth in the product documentation and/or on Microsoft's support web sites, and uses the latest updates, patches and fixes available for the .NET Component and the relevant Microsoft operating system; (4) it shall be sufficient if you make the disclosures provided for above at a publicly available location such as a website, so long as every public disclosure of the results of your benchmark test expressly identifies the public site containing all required disclosures; and (5) nothing in this provision shall be deemed to waive any other right that you may have to conduct benchmark testing. The foregoing obligations shall not apply to your disclosure of the results of any customized benchmark test of the .NET Component, whereby such disclosure is made under confidentiality in conjunction with a bid request by a prospective customer, such customer's application(s) are specifically tested and the results are only disclosed to such specific customer. Notwithstanding any other agreement you may have with Microsoft, if you disclose such benchmark test results, Microsoft shall have the right to disclose the results of benchmark tests it conducts of your products that compete with the .NET Component, provided it complies with the same conditions above.
|
|
|
|
|
I have a fire alert application that for no reason what so ever should be closed, this you can fix by adding the following in the Form_Closing event e.Cancel = true;
But how do I hide the closing X icon? 
|
|
|
|
|
The 'x' icon on the upper right is the control box. If you go to your form style, under windows style, change the ControlBox property to 'false'. Although i'm not sure if the user can still close the window by pressing alt-f4. You may need to intercept the key event for this.
-Steve
|
|
|
|
|
When you disable the closing event then it don't care if you alt-f4... only thing that can close it is to kill the process in Task Manager.
But thanks .. for the reply 
|
|
|
|
|
Is there any way to regain an instance of a class that has already gone out of scope?
For instance:
Private Sub cmdGo_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdGo.Click
Dim i As Integer
For i = 1 To 100
f = New frmTest 'f has been globally declared as a Form
f.Show()
Next i
End Sub
This code instanciates 100 instances of a form and displays 100 forms.
The instance almost immediately goes out of scope due to the for-loop.
Should I now run f.close, only the last form is closed understandebly, but how do i reference the other 99 forms? Garbage collection doesn't destroy them because they are still active on the screen.
you can't forget something you never knew...
"Watching Migthy Joe Young made me hate my life..................................I want a gorilla!" A. Havemann
|
|
|
|
|
evilnoodle wrote: but how do i reference the other 99 forms?
By storing them somewhere you can get at. Add them to a collection of some sort, then iterate through the collection.
|
|
|
|
|
I'm not at very skilled VB programmer and quite new to Visual Studio 2005. I'm trying from an ordinary batch-script on windows to call a VB program, which - depending on the parameters - should set one environment variable.
I have managed to create the program, and I can see either through registry or through "Environment Variables" in "System properties", that my variable is created and set in either the user or machine environment. But in the command shell (cmd.exe) window I still have no access to the new environment variable.
I imagine the problem is that when launching the cmd.exe you take a kind of snapshot of the environment and works with this "copy".
But how can I refresh the environment so the variable is visible and the new value also?
Rgds.
Preben
|
|
|
|
|
P.Meyenburg wrote: I imagine the problem is that when launching the cmd.exe you take a kind of snapshot of the environment and works with this "copy".
Exactly, your existing shell won't see env variables created after the shell started. Try to run cmd.exe again on the existing command shell window and see if you can see the new env settings.
P.Meyenburg wrote: But how can I refresh the environment so the variable is visible and the new value also?
Even though the existing sheel can't see new env variables, your code should be able to use them immedediately after they are created.
Best,
Jun
|
|
|
|
|
Thanks for your reply Jun.
But as you wrote:
Jun Du wrote: Exactly, your existing shell won't see env variables created after the shell started. Try to run cmd.exe again on the existing command shell window and see if you can see the new env settings.
I have triede this, but it seems that a new cmd.exe inherits the environment from the old one, so it did not help at all.
In my search after a solution I found:
[^]
But even this have the same problem as I. When you call it from a cmd.exe the same problem arise, I can't access a variable newly created, but I can see it in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
So the big question, what is the trick to get it visible in the current environment?
Rgds,
Preben
|
|
|
|
|
Hi All,
I have added DataGridViewComboBoxColumn to the my DataGridView.
Can Any One Suggest me How to get the Selected Item From DataGridViewComboBoxColumn;
Thanks In Advance
G.Nagaraju
|
|
|
|
|
Check out this link
http://www.datagridgirl.com/
Hope it will help u
Navi
|
|
|
|
|
Does anyone know how?
thanks
|
|
|
|
|
Not sure if this is what you want, but give a try to Win32 call SystemParametersInfo(SPI_SETDESKWALLPAPER, ...), which can change your desktop wallpaper.
Best,
Jun
|
|
|
|
|
|
|
Actually I have seen this with non-.NET programs as well. When an app gets minimized Windows can swap out memory that is not needed and free things up. I just did this with Word and it went down to 1-2M when minimized and then back up to about 5M when it is brought back up front. Another app that we run here at work went from 18M while it was running, down to 1-2M when minimized and then back up to 6M when it was opened again. This definately is not anything to do with .NET itself.
Steve Maier, MCSD MCAD MCTS
|
|
|
|
|
On minimize, two things happen. THe first is that the framework releases most of the extra memory it's allocated from the OS to cover against future requests. Since form initialization uses alot more memory than is needed during runtime, apps that don't substantially increase the ammount of data in ram after loading the form tend to have a large amount of extra availabl. The amount held is determined by the framework, and is partially dependent on how much the system has available. The reason for de/allocating in large chunks rather than small ones is that getting memory from the OS is a costly operation. A system wide memory shortage will cause the OS to send 'return extra memory' messages and do the same thing. The second is that most of the app is moved from system to virtual memory. On restore, the code is only moved out of VM on an as needed basis.
|
|
|
|
|
PS Your apps memory usage isn't much higher than mine which runs happily on an NT4/p3-500/256mb testbox, unless your client machines are substantially older or already heavily burdened with other apps you shouldn't have a problem.
|
|
|
|
|
The 'Mem Usage' column in Task Manager is actually the current working set size. The working set is the set of physical memory pages which the OS thinks are currently necessary to run the program. Periodically, about once a second, a thread in the OS called the balance set manager wakes up and trims (removes) pages from each working set on the system, to ensure that there are always enough free physical pages of memory to satisfy demand. There is also an upper limit of working set size for each process, which is defaulted to about 1.5MB, but this is really an advisory limit - if there are enough free pages, this number is ignored. You can set your process's limits with the SetProcessWorkingSetSize function, but there's no benefit in doing so.
When the USER subsystem minimizes a window, it automatically asks the operating system to trim the process's working set, since the assumption is that you aren't going to be using it again straight away. You can get the same effect by calling SetProcessWorkingSetSize, passing -1 for both minimum and maximum working set size parameters.
Pages are added to the working set by allocating them, or, after they've been trimmed, by accessing them. If your program has good locality of reference, the working set will normally stay quite low.
To see how much load you're putting on both physical memory and the page file, enable the VM Size column. This is equivalent to the Process: Private Bytes counter in the Performance tool (in Administrative Tools).
The .NET Framework manages all your allocations from a set of virtual memory allocations. The garbage collector generally just moves data around within the existing allocations, until its newest generation becomes full, at which point it will ask the OS for a new block (referred to as a segment). If it does have a completely free segment after performing a collection, it may return it to the OS - this is the only way that the VM Size column will go down.
To keep the size of the GC heap down, ensure that you're getting rid of your objects promptly. If an object implements the IDisposable interface, or otherwise offers a Close or Dispose method, you must call it when you're finished with the object. If you don't, when the GC runs (and the object has a finalizer) it will go onto a queue (called freachable) for the finalizer thread to run the finalizer. The memory will only be released back to the GC heap when the GC runs again to collect the older generation that the object is now in, after its finalizer has run.
Other things to do are to simply allocate fewer objects. .NET applications can often be 'object-happy' - it's so easy to create an object that it is often done without thinking. To see how many objects you're allocating, and where you're allocating them, run CLR Profiler[^] (for 1.1[^]).
For more on how the GC works, see Maoni Stephens' weblog[^] and this presentation[^] (PPT, 401kB) from PDC 2005.
-- modified at 16:25 Wednesday 23rd August, 2006
|
|
|
|
|
The responses by Dan and Mike are absolutely correct. You also should not rely on GC.Collect, as it interferes with the natural GC collection schedule, which can actually hurt your application performance. The GC runs on its own thread and actually freezes your applications main thread while it is running. Instead of calling GC.Collect when the child form is closed, you really should be calling the Dispose method of the form.
In addition to the blog mentioned, you can check http://www.codeproject.com/useritems/idisposable.asp[^] for an explanation on how to implement the Dispose pattern.
|
|
|
|
|
I know that value type variables are stored in stack and ref variables are stored in managed heap. I wanted to know why.
Thanks in advance
|
|
|
|
|
In most cases (not within classes), ref variables are on the stack as well. They refer to objects allocated on the managed heap.
Best,
Jun
|
|
|
|
|
karan vidyut wrote: I know that value type variables are stored in stack and ref variables are stored in managed heap. I wanted to know why.
I think you mean "value objects" and "reference objects".
|
|
|
|
|
Reference types (e.g. objects) are always stored in the heap.
Value types declared inside a class is stored inside the object data on the heap.
Value types declared as local variables in a method are stored on the stack.
If reference types would be stored on the stack, they would live exactly as long as the method call where they are created. They could not be freed earlier and not survive after. Also the stack has a limited size (2 MiB by default, IIRC) and can not be expanded at runtime.
If local variables would be stored on the heap, it would mean that most method calls would allocate memory on the heap, vastly increasing the heap turnover and adding a lot of overhead.
---
b { font-weight: normal; }
|
|
|
|
|
How to emulate the File->Send->Page by email functionality given by IE.
Is it possible to achieve the same result on click of a button using asp.net
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
