I have visual studio solution with 2 projects - ImageBrowser (win forms) and ImageBrowserInstaller (WiX).
Assuming that it's a not stand alone product but meant to be enterprise and client that
acquires it want it to have certain name, for instance Picture Viewer. That means that the product folder name will change, programs and features entry and so on.
Is there any friendly way to do so? some delimiter that i put in XML that value i can provide during compilation? or I will have to have set of projects for this need?
Hope the question is clear.
You would need to change the Application settings before compilation.
Related
I am making an extension for both VS2010 and VS2012 that has a toolbar command.
Given the change in icon style between them, I want to provide a separate icon for each.
How do I specify that in .vsct? I assume I might be able to use Condition, but I am not sure if there is already a pre-defined value with VS version.
It seems it is not possible without using an MSI, see "VS Package (VSIX): Having two different toolbar icons for VS2010/VS2012" on MSDN forums.
Ryan Molden (MSFT):
I do not believe you can use VSIX to install or specify target specific resources. VSIX is intended as a very simplistic deployment mechanism, it is in fact just a renamed ZIP file plus an installer with a small amount of logic to process pkgdef files. If you want more complex installs (like laying down different dlls based on your install target) I believe you would need to create an MSI.
We recently switched to team foundation server 2010 for our source code management, everything works just fine, except for some legacy code written in FoxPRO 7 and 9, source code files are some sort of tables. For Forms, there are two kind of files, one ending in .scx and another in .sct, both can be explored using the fox studio but there is no way to open them in a text editor.
does anyone have any experience getting the fox code to work/merge... on TFS ?
I'm not aware of all of the ins and outs for source control and FoxPro, but if some of the source is binary, you can configure file extensions to disallow merges.
Right-click on the collection (root node) in the TeamExplorer window. Go to Team Project Collection Settings | File Types.
You should be able to add the extensions (like .sct), and specify that merging and multiple checkout is not allowed for those files.
The downside will be that only 1 person at a time can check those files out, but since the forms are FoxPro tables, I would imagine that's the same problem that you would have with any source control tool.
For merging you can set up a merge tool that is capable of merging those files. This must be done on every developer station (Tools->Source Control->VS Team Foundation Server->Configure User Tools).
It may be that VS uses a server-side merge tool to do auto-merges, I don't know if or where you can change that.
I've worked with VFP since it was FoxBase back in late 80's. Visual Foxpro used .dbf files (renamed extensions) for purposes of building forms (.scx/.sct) and visual class libraries (.vcx/.vct) and reports (.frx/.frt).
I've written some code to run through a given project and dump out a text version of all the code as if it was all text-based. All the controls are dumped in alpha order, embedded procedures, etc too. List all property settings in same place too.
Its not PERFECT, but I've used over the years in comparing source code versions when dealing with other developers who liked to change things and not notify me (or others) of such changes and finding later by other horrendous means.
If this is something you might be interested in, I can strip-down the code (some) and send it to you via an email, but would need an email address. The code is written in VFP as a .prg file, so nothing compiled that you would need to worry about any viruses or anything.
At least this way, you COULD get a text version associated with the binary pair's of files used within VFP.
We have a VS2010 Solution which contains one windows form application and 4 Class Library (DLL) projects. (The class libraries are things like BusinessTier, DataTier, CommonCode, ControlLibrary) The whole thing is targeted for framework 2.0. Its been like this for three years.
Ok
So our application has grown to the point where we want to add a large new feature and marketing wants to deploy it as a separate product. Our product is used to fill in tax forms and the second product will fill in other tax forms.
We want to end up with two exe's (two install MSIs) which will be sold/installed/updated independently and could both be run at the same time on the same computer. Most of the code is in common between the two apps.
I am trying to figure out the best way to structure the solution to create the desired outcome.
1) Option one could be to create a new EXE project and several new DLL projects in the same original solution (Say in a solution folder) which have unique names,versions, guids, etc. with most of the code files as links back to the code files in the original similar DLLS. This allows us to have two completly separate systems with unique names for all the files, version numbers, etc., but allow any customization to be made to each project/dll. Is this a good idea or overkill?
2) Option two would be to create a new exe project in the solution and link to the same dlls as the first exe project. This seems simple enough, but i do not know if it is a good idea to have two projects which use the same DLLs. I do not really want to use the GAC. If we have two exe's which use the same Dll's ( even though they will be in separate application folders) with there be a problem if the DLLS have the same/different version numbers, name or GUID?
What are your ideas?
How should i restructure the solution to accommodate the new product?
Go for Option 2
There is no problem with the same Dlls with the same names. If you deploy the exes to separate folders or keep them in separate folders it will work either way.
I would even go further and look how you can break the application up further into more assemblies/dlls as it will give you even more flexibility. I would also have a single File for AssemblyInfo, and Add it as a linked file to all your projects. This means you have have a single version across all your dlls/exes.
http://vsh.infozerk.net/options/add-an-existing-file-to-a-project-without-copying-it/
I don't know if this is possible at all:
I have one project in Visual Studio express. Now I would like to create multiple executables (handy small applications) out of that project. These executables are different of course. But the entire functionality is in the source code of the project (of course). The point is: Depending on the value of one variable some functionality and buttons and so on is disabled and other is enabled.
Now I would like to iterate through all of the possible values and would like to have the corresponding executables created. I wouldn't like change the value of this variable by hand.
Best would be to have an array or so that keeps all of the values and Visual Studio iterates through this set of values to create the executables (with a specific name each).
Hopefully my description wasn't not too confusing.
Maybe my approach is completely wrong.
Does anyone know an approach to solve this?
Thank you!
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.