Develop Reference

some computers, the "Windows Installer" is retrieved again from the C # program that was loaded when the program was run

I have packaged a C# application using VSI_bundle.exe, and when it is installed on some PC's, the following message appears when trying to run the application.
Windows Installer >>>
"Please wait while Windows configures (Product Name)"
The application will then run fine, but when I turn it off and back on again, I get the same situation again. How can I fix this?

The message dialog means that the installed product is being repaired because it's damaged, not the same as when first installed. The Windows Event Log (Application) will have an MsiInstaller entry saying something about the ProductCode and the component that is missing.
It's a feature of Windows Installer that it repairs installed items that get removed, so if the application changes or removes files or registry entries then Windows will want to reinstall them. It's the same as going to Programs&Features and doing a Repair on the product.
Fixing it depends on why it's repairing. For example, is the app deleting files or registry entries, and if so then why?
Sometimes people install the MSI with DISABLEADVTSHORTCUTS set to 1 to prevent the shortcuts from doing the repair, but that cannot prevent all repairs, and may be disguising the fact that the app is removing required files.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368297(v=vs.85).aspx

As others have pointed out, this seems to be a Windows Installer self-repair or "resiliency" issue.
Launching your application via an "advertised shortcut" (good Symantec article on the topic linked) will trigger a key path check for your MSI to determine if your product is properly installed. During this process a discrepancy is found, and a self-repair is triggered to install what is missing.
In certain cases the discrepancy can not be resolved by the self-repair, and it then keeps repeating in vain. Essentially you need to determine what component causes the discrepancy and hence triggers the repair.
Perhaps you can try Stefan Kruger's msifaq first, it is terse and to the point: Windows Installer launches unexpectedly, for no obvious reason.
I have written about self-repair too many times, one of the shorter answers might be this one: Why does the MSI installer reconfigure if I delete a file?
For future reference I include some links on the topic of Windows Installer self-repair or "resiliency":
Comprehensive explanation of self-repair, verbose and comprehensive: How can I determine what causes repeated Windows Installer self-repair?
Solution focused description of self-repair, attempting to find real-world solutions: What do I do when launching an application triggers repeating, endless Windows Installer self-repair?
Self-repair issues for developers, avoiding the problem in the first place: How do I avoid triggering MSI self-repair with my WiX / MSI package? (perhaps try this one too, should be a quick read and written specifically for developers).

Check your event viewer for windows installer related messages. Most of the time it will show the componentID that triggers the repair that Phil mentions. Take this GUID and search your installer or use a tool like InstEd! to open the MSI and search for the guid in the components table.

Making an installer

i have tried every guide possible but i just cant seem to make an installer for my application.
I keep getting errors / warning about my dll files (ieframe.dll and another custom chemistry control) which says the following files may have dependencies that cannot be determined automatically. Please confirm all dependencies have been added to the project
I have no idea what to do, every dll file under references in my main project is set to copy if newer and all the dll files appear in my installed folder when i run the installer.
does anyone know how to fix this.
Thanks
edit: when i run the installer i get an error with the dll saying
Module C:\....... .dll failed to register.
Any ideas?

It is not an error, it is a warning. Is is hard (if not impossible) for Visual Studio to find out if all dependencies of a COM dll are taken care of by the installer. This is why Visual Studio is warning you to have a look.
This is not something to fix.
EDIT after adding more to the question
The message you are getting might be related to the warning but it doesn't have to be.
If it is a COM DLL (and I suppose it is because those need to be registered) it might depend on another dll that should be present before being able to register it. It is also possible that another prerequisite is not met; e.g., a specific OS version.
Did you check the eventlog for more information? Can you tell us the actual name of the dll? I noticed this message also when trying to register a 64 bit dll on a 32-bit OS but there can be many reasons.

I would suggest you to use some external Application\s like Smart Install Maker or Install Shield

Error Message With Installer of C# Windows Service

Here is the error message: The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDialog,
I found another link related to the problem. The link here
Will cleaning the registry work. I tried the tool mentioned there but it needs registration.
Can this be resolved

This cannot be answered without knowing more about your installer and the context that you are installing it. Generally you aren't following MSI best practices and you are getting into a situation where you don't have the proper privs to do the install.
This really doesn't have anything to do with the fact that you have a service although if you are using an InstallUtil custom action consumed by an Visual Studio Deployment Project installer then your problem is probably that VDRPOJ is so broken it schedules deferred custom actions with impersonation instead of system context.

I have resolved my problem. It was a critical one really.
Here is what happened:
The service I wrote crashes soon after starting. While crashing, it probably holds onto few resources and hence when I try to uninstall it, it wont be removed from the list of services, that is, it is never removed from registry.
Now that it's still entered on the registry, I can neither install or uninstall it. The .exe has been removed in last un-installation, therefore there is nothing to uninstall.
The solution was to manually remove the entry from registry. I have changed my code so that it doesn't crash or at least it's handled as an exception.

Visual Studio 2008 crashes when opening solutions in a TortiseSVN directory? How do I fix this?

I'm using TortiseSVN for my subversion client on a Windows Server 2008 box and I've got a folder with code checked out into it.
When I go to open the solution file that's under source control Visual Studio 2008 starts and before it can even finish loading the solution from what I can tell Visual Studio crashes. I'm trying to open a solution that has VB code in it. It gives no error messages or warnings. It's just gone.
I have checked the files and they all seem fine. The solution file seems fine when I look at it with a text editor.
This is also Visual Studio 2008 SP1 and I've got all the latest .NET service packs installed.
Has anyone else seen this before and know how to fix it?
Edit: I just did an SVN export to a new directory and it still crashes in the exported directory where there is no longer any SVN attached to it.
Additionally, it crashes EVERY time I try to open the project that came from SVN.

You should be looking at the solution file with an xml editor, at least then you will get some help for subtile flaw's in the formatting or something like that.
You can also submit feedback to Microsoft on the VIsual Studio Connect site, if the bug turns out to be real.
Some commonsense things todo however would be, goto your visual studio command prompt, start off with "devenv /ResetSettings", that often helps isolate any weirdo add-on or something lke that.
Also, try to build clean with msbuild or vcbuild, then build fully with either one (i.e. if vcbuild can not build your solution, use msbuild). That can help by laying out the symbols and such and maybe clear out some corrupted file or something.
You also may have .suo files from your subversion, those are binary files that do contain some settings, it's common for people to accidentially check them in, but they are usually better off being kept on a per-developer basis (not in the source tree). The /resetsettings will likely clear these out also, but you may want to make sure.
You can also double check the path's to all of the assemblies referenced, that your not going from a 32/64 bit host, and the CLR DLL's are in different path's now etc...
One last thing, if your really stuck, you can get a stack trace and debug the crash a bit ;), see where the fault is occuring and search that module online, your'll often find that somebody may have a specific solution.
Oh yeah, also, hooker's can be trickey. Don't trust them for a minute. Make sure you set tsvn's "only load in windows exlporer" option and configure it specifically for what folders on your system have local-svn working directories, this will greatly reduce the working set for their shell extension. On most any system, over time, one program or another (apple irw.exe or adobe pdf-preloader.exe sort's of ad-ware) will try to work it's way into your shell. You should try to make sure your dev box is rather clean from anything hook's, simular to what VladV was saying...

I had a similar problem and I fixed it and afterwards I wasn't quite sure how I managed it.
It basically involved going to the tools/options menu and setting the source control plugin to none. However, I obviously had to have had the solution open in Visual Studio if doing this was to fix the solution, but yet I thought the problem was I could not open the solution.
The only possible scenario would be if I was able to open the solution, but not open any of the projects inside it, hence able to change the source control settings immediately after opening the solution.
Does that make sense?

Try opening your solution and projects files in a text editor, and looking for anything strange.
I once heard of a similar problem: a solution contained SVN bindings created by AnkhSVN, but Visual Studio had no AnkhSVN installed, and failed to open the solution without giving any meaningful error information.

Unwanted MSI appearance after installation

I used windows installer (msi project) and actually I have the msi file after installation it throws a shortcuts to the desktop.
My problem is when i double-click on the shortcut for my application, it displays somthing like the installation then it runs my application. I don't want the installtion windows to appear where my application doesn't need to throw any file or to install something before running all pre-requests are installed through the msi file. I want that when the end-user clicks on the shortcut, it runs the application directly ...
I hope I explained my problem well.
One additional note i'm using VS 2005, C#
What if i want to remove this action where it always happens. everytime i double click on the exe file it appears this window . my application is not so complicated to so.
EDIT: where can i find the log file ?!?
please help.
thnx indavence

One of the "features" of the MSI installation system is that it can automatically repair some things when your application is run.
A good way to see this in action is to have two versions of Microsoft Office installed side-by-side. After running MS Word 2007, an invocation of MS Word 2003 will start with MsiExec popping up to fix a few things before the application starts.
Almost certainly, what you're seeing is this kind of repair - check the log file and find out what is being fixed, then alter your installation project so things aren't broken on first install.
Hope this helps.

That quick installer operations you saw is very often issue. I think it appears only on first run and never again. Never mind. Maybe Windows Installer service makes some registration, etc.

You might want to refer to How Windows Installer Shortcuts Work and Windows Installer Logging
The easiest solution if you really want to avoid this behaviour is to manually add a shortcut rather than having Windows Installer do it for you.
My guess is that you've probably got some HKCU keys in the installer that need to be checked/repaired for the current user. Have you run MSI validation? This can often highlight issues that cause unnecessary repairs.