I have a WinForms application that uses a config file to specify where it's external files will be created.
Is it possible to use the installer to question the user where the files should be located and add this value to the config file?
It would also be good if I could confirm that the user has entered a valid path but that's just a "Nice-to-have" at the moment.
Following the helpful hints from Pete, I was able to find this blog that does exactly what I need.
There are a few Gotchas to watch out for and I've covered them here but these may be Visual Studio 2008 specific issues.
Related
To All,
I haven't used a Visual Studio in quite a few years, and don't remember what version I had used. I created 15-20 libraries and 30-40 utilities - all in C.
I recently decided that I wanted to enhance some of the libraries and utilities and acquired Visual Studio 2010. I open an existing project (.dsw) and I get a popup that says "The project ' must be converted to the current ... Convert and open this project?' I click on Yes. I then get a popup that says "A file with the same name ... already exists on disk. Do you want to overwrite the project and its imported sheets?' Again I say Yes.
I go along my way and make a bunch of changes to the project. I click on "Save All." I then close the project and when I reopen, it is like I didn't change anything! I get the same popups again!
I've check the permissions on the directory and files and they should be writable. I have SCOURED the net trying to find out what I am doing wrong to no avail.
Any helpful pointers would be greatly appreciated!
TIA,
je
.dsw extension was used by Visual Studio 6, Visual Studio 2010 project files have extension .vcxproj. The conversion process mentioned in your question creates those new project files. Open them instead of old .dsw
I have built one windows forms application and I published for client installation. While installing the setup file, it should ask the user to select the installation directory path; instead, it's installing in default path as below :
C:\Users\Mysys_t\AppData\Local\Apps\2.0\434YBBVC.Z2H\TNYPR09N.1JZ
Is there any settings to do this, so that, while installing, user is able to select the installation directory?
In general, the answer is no. See a related MSDN forums discussion among other online references that explains why: ClickOnce was designed to automatically manage installation directories to prevent deployment collisions.
Now...the referenced MSDN forums discussion also links to one way to possibly work around this. Certainly anything is possible with some ingenuity and work (e.g. publishing a setup wrapper with ClickOnce to leverage ClickOnce's auto updates but use indirection to control where your actual app ultimately gets installed); but this is not possible using ClickOnce "straightforwardly".
this can be achieved by
Creating an MSI Package for C# Windows Application Using a Visual Studio Setup Project
pls follow the link below :
http://www.c-sharpcorner.com/UploadFile/1492b1/creating-an-msi-package-for-C-Sharp-windows-application-using-a-v/
I want to create a Visual Studio 2010 setup project that deploys some files to a folder where my application can use it from. I want it so, that all users have the same files, and that they also could manipulate them without admin rights.
Thus, "Common Application Data Folder"* as described in this MSDN article, seems fine.
However, in my Visual Studio 2010 setup project I did not find the "Common Application Data Folder" available in the "Add special Folder..." drop down menu.
I have a .NET 4.0 WinForms app and see no reason why this does not show up.
The user's common application data folder is available but does not match my intended use.
Thanks for any hints!
Visual Studio setup projects do not have a predefined folder for common Application Data. However, you can install files in it like this:
add a custom folder and select it
in its Properties pane set DefaultLocation to:
[CommonAppDataFolder]
in this folder add the files you want installed in common Application Data
During install CommonAppDataFolder will be automatically resolved by Windows Installer.
A more specific solution might be to set the DefaultLocation property to:
[CommonAppDataFolder][Manufacturer]\[ProductName]
Manufacturer and ProductName will be resolved from the values you assign to the corresponding properties of the setup project.
I'm building a Visual Studio Package and associated with it, I have an app.config file (which contains some information about connecting to a WCF service).
As far as I can tell, this package is actually connecting to the devnev.exe.config configuration file (if I use AppDomain.CurrentDomain.SetupInformation.ConfigurationFile), it will retrieve the path to the devnev.exe.config
Firstly, is this correct? Shouldn't the package automatically pick up the app.config file? If this is the case, then how can I make the project use the app.config file?
I'm running VS2010 Ultimate, programming in C#.
A Visual Studio Package will take the devnev.exe.config configuration file as its main configuration file. If you add an app.config file into the project, it will not accept it. This is because the package is running within Visual Studio, therefore it is accepting Visual Studio's config file.
At the same time it is not good practice to change the devnev.exe.config file, since once you deploy your application, the user will also have to change that file (and on the whole, you shouldn't change that file).
What I ended up doing is connecting to the WCF service programmatically.
Hope this helps somebody.
When you compile your project the app.config is compiled as [exe].config.
If you want to change configuration you can change the content of [exe].config (it's a plain text document).
We are using Visual Studio 2008 to develop a winforms application stored in Visual Source Safe 2005.
If one of our team members changes a *.Designer.cs file without changing the form's source file the change doesn't appear during a "Get" operation. However, if in Visual Studio you run a compare on the *.Designer.cs file the differences are displayed in the difference viewer.
FYI: We are using the default Microsoft Visual SourceSafe plug in for Visual Studio.
Any ideas why the "Get" operation will not detect changes in the *.Designer.cs files and suggest we pull down the latest version?
Thanks for your help!
Designer files are not intended for manual manipulation. One of the chief incentives for adding partial classes to the popular .Net languages was to segregate the designer-generated code from manual user code, in fact. Manual manipulation of repeatedly-generated code (in pretty much any environment, not just visual studio) is asking for headaches.
What changes are you making to the designer file, and why is it not possible to make those changes to the non-designer source file?
Edit:
Is the project in the IDE properly bound and connected to the source control database (via File->Source Control->Change Source Control)? It should automatically be checking out the designer files when changes are made in the designer view.
I would try doing a Get manually through VSS Explorer (i.e. not through Visual Studio) and see if it works. If not, check to see if the file is pinned to a previous version.
Woe unto you for having to use SourceSafe. At my last job, we used SourceSafe and had a myriad of problems with it. We switched over to Surround SCM and were really happy with it. I'd never heard of it before that job.
To answer your question, any time I ran into a problem like this with SS, I'd do a "forced get": in the options dialog when you get latest, tell SourceSafe to get the latest version from the server regardless of whether it thinks the file is up to date.
Edit: I think the issue is the VS200X plugin for VSS. If you have the VSS standalone application you should be able to do a forced get from there. I now remember having to do this so often that I stopped using the VS200X plugin.