We have a Windows Desktop only product suite that consists of several .exe applications and (obviously) quite a bunch of shared libraries between these apps. There's about 20 exe apps and maybe also about 20 shared libraries that are each used by several of these apps (some libs are very specific, some are just your good(?) old FooUtils.dll) Most code is C++, some C#.
Currently, all these reside in a single Visual Studio 2005 solution and are all built and released together. That works quite fine and each developer always can edit / see / debug any code he needs to. About 15 devs (mixed C++ / C#) on that product suite.
Now the problem
Due to migration pressure (language features, new 3rd party components) it becomes increasingly urgent to migrate some of the apps (read .exeprojects) to newer visual studio versions. Some to VS 2010 maybe (3rd party dependencies) some to VS2015. And some we just have not the resources to migrate them from VS2005 yet (third party constraints, as well as time/budget constraints).
This means that several of the shared C++ libraries will have to exist for several visual studio versions. (As opposed to the exe projects - these would just be built/maintained for one chosen VS version.)
Now the question
Given a set of (internal) shared libraries that need to be created for multiple different Visual-C++-Versions and that should be easily editable and maintainable for all devs, how are we to keep the Utils.vcproj(2005) the Utils.vcxproj(2010) and the Utils.vcxproj(2015) in sync?
Mostly to avoid manually having to maintain all files contained in the projects, but also regarding project settings / .[vs]props settings for these projects.
Ideas we had so far:
Just accept annoying triple maintenance of 3 project files in 3 different solutions (ugh.)
Use one of the vc.. project files as the master project and automatically (how??!) generate the other vc..files from it.
Use tools like CMake, Premake, ... ?? to generate these shared-shared library projects. (That would mean introducing a foreign configuration tool for our devs)
If you want to avoid manually updating your project files in separate versions of Visual Studio, you'll have to have a master configuration for the project of one sort or another. The two options you listed are basically your options:
Use one project version as the 'master'. In this case, the master must be the oldest version (VS2005 in your case?). Visual Studio has a project upgrade feature, to convert older projects to newer versions. When you load up an older project in a newer version, it prompts you to upgrade. This process can be automated with some simple scripting. Using devenv.exe <project/solution file> /upgrade you can upgrade a project from the command line.
Use CMake/Premake/etc. These add a little bit of overhead, but making supporting new platforms and configurations a lot less painless. If adding new dev tools is cumbersome to your process, and you're only supporting Visual Studio, the first option might be more suitable.
Related
When an older solution file is opened from a Visual Studio version higher than the one it was written on there are almost always errors. The logical approach might be to start with the updates to extensions but that also causes issues along the way.
Is there a specific set of instructions regarding the better method to use while upgrading an old project to a newer version of Visual Studio?
Example:
There are three updates pending:
1) Live Share
2) ML.NET Model Builder 2019
3) SQL Server Integration Services
There are 559 errors (first four as examples):
Optimization does not exist
BundleCollection could not be found
Mvc does not exist in the namespace
GlobalFilterCollection could not be found
Should the Updates be the first place to start?
Is there a better methodology for this upgrade process?
Changes to the project model from one version of Visual Studio to the next may require that projects and solutions be upgraded so that they can run on the newer version. The Visual Studio SDK provides interfaces that can be used to implement upgrade support in your own projects.
To support an upgrade, your project system implementation must define and implement an upgrade strategy. In determining your strategy, you can choose to support side-by-side (SxS) backup, copy backup, or both.
You can review this document for workarounds for solutions created in earlier versions of Visual Studio to open in newer versions.
https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/upgrading-projects?view=vs-2022#upgrading-custom-projects
Using .NET Core, is there a way to have content-only projects in Visual Studio 2017 (no output dlls but automatic copying of content for other projects)? I'm after essentially the same thing as this post, save that I'm working with .NET Core.
I saw something about Shared Projects and wondered if that'd be the appropriate solution. Not exactly sure how they work with .NET Core, though (or if they're even supported).
I did some digging into how Shared Projects work. This appears to be exactly what I'm looking for, provided I don't encounter any major caveats or showstoppers down the road.
For others that are new to Shared Projects, they appear in a separate selection below Projects in the navigation tree of the Reference Manager (when adding project references).
We have several different teams building C# applications with Visual Studio. When we want to share libraries across teams, we create nuget packages for the libraries and add them to a local nuget feed.
The process we use to package our libraries is very simple: we create a .nuspec for the library, and then run nuget on the project .csproj to create the package.
This results in a package that is specific to the .Net version (4.0, 4.5, 4.5.1) selected for the .csproj for the project. We've pretty much standardized on 4.5 to deal with this.
Many publicly available nuget packages provide simultaneous support for different library versions, and we'd like our packages to do the same to make it easy for each of our teams to select .Net versions appropriate for them. I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams.
So my question is: is there an easy/standard way of setting up a library project in Visual Studio so it produces a cross-version-compatible Nuget package?
Not a direct answer to your question, I know this, but...
Why target multiple versions of the framework at all?
When NuGet installs a package that has multiple assembly versions, it
tries to match the framework name of the assembly with the target
framework of the project. If a match is not found, NuGet copies the
assembly that's for the highest version that is less than or equal to
the project's target framework.
Matching assembly version to the target framework of a project
What we've done is figure out what our lowest common denominator is, both for our libraries and our organization. In our case, we have some older apps still running on the 3.5 framework, so any NuGet packages we have that need to be available to any/all projects also target the 3.5 framework. However, we also have a few libraries that are only needed by some newer apps, these target 4.5 (both the projects and the libraries). This lets us leverage newer features.
If we find ourselves in a situation where an older app needs to reference a package that must reference the newest version to work, we bite the bullet and upgrade the project. However, for our libraries/packages, we always target the oldest version possible. Basically, the split is where we want/need to leverage Async/Await.
TL;DR: Don't target multiple frameworks. Target the lowest common denominator. It provides motivation to upgrade those apps lagging behind on 3.5 or 4. (Or, God forbid, 2.0...)
If you really need to support different framework versions, you will first have to create different configurations for each framework version (in your .csproj files), utilizing the configuration manager. Similar to the standard configurations "Debug" and "Release", or "x86_Debug" etc. you can add configurations by yourself like Release_Fw_40, Release_Fw_45, Release_Fw_451.
When packaging with Nuget, you can use the parameter
-Prop Configuration=Release_Fw_40
to choose which configuration you want to build, as described in the Nuget docs. There are also some hints how to automate the package builds, including support of different configurations.
Note that this will impose some additional effort for your library maintainers to manage those many configurations. It should be obvious that even if you provide a "Fw 4.5.1" version of your lib, you can only use Fw 4.0 features in the source code as long as you want to support a Fw 4.0 configuration. So make sure what you are trying is really worth the hassle.
I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams
I am not sure what you meant by this sentence, maybe I am telling you only things you already knew. But "moving files around to different folders" and "invoking the nuget packager at a lower-level" are things which can be very easily scripted. For such tasks, you can use simple Windows shell scripting or Powershell scripting, whatever you prefer.
I've been writing C/C++ for years using Xcode and am very comfortable with *nix systems. Now I'm working with people who only understand Windows; I've decided to try to learn that environment too.
I was thinking that google would be my best friend, but even the terminology for VS is sufficiently orthogonal to that of Xcode that I can't make any headway. (E.g., what's the equivalent of "Add new Target to project" for VS?)
Can anyone point me to a guide to VS for Xcode practitioners? I've seen lots of translators going the other direction.
Thanks!
I do not know of any XCode to VS Guide, but according to XCode Documentation:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
The analogous concept in Visual Studio would be a project. In Visual Studio, a project contains code files, assets and settings which compile into an output of some sort. (Could be an executable, a DLL, a website, or a few other options...) Projects can reference other projects or other external libraries (System or user libraries) which are all delivered together at compile time.
A solution contains multiple projects which can be related (referenced) and compiled and linked together.
When you first start VS, it will ask you to Open or Create a project. It usually will automatically create a solution and automatically add the project to it. To add additional projects, you can right click the solution in the "Solution Explorer" and add another project.
Hope this helps
I believe what you're looking for is the Build Configuration Manager in Visual Studio. (It's been a while since I've used XCode). As I recall a "Target" in Xcode is how you want the project built. In VS you get a Debug and Release configuration by default but you can use the Build menu and choose "Configuration..." to create more.
I don't know of a tutorial for XCode users but Kate Gregory has some nice beginner screencasts on pluralsight for using Visual Studio 2010. Those may get you over some learning curve hurdles. I think they have a 30 day free trial. If you move on to .NET development they have a lot more that can really help you get up to speed quickly.
Quick Terminology
In Visual Studio you typically create a Solution. A solution can consist of any number of Projects. You can add projects for .DLLs (libraries), services, applications (gui and console based). You can have multiple applications but can only designate one as the Startup Project.
In my typical project I start with the GUI and Add a project of the type I want. Then I often add a library project for new code that I think I can use across multiple applications. Existing code in both supplied libraries and ones you've built are added as References. You can right-click on References in the Solution Explorer and select Add References.
In XCode (when I used it) your IDE consisted of two pieces, XCode and Interface Builder. In Visual Studio you can build interface elements directly in Visual Studio ( but there is also a tool called Blend that allows for UI creation and modification). There are THREE major types of interfaces web (usually an ASP.NET application), WinForms and WPF. I think of WinForms as the equivalent of what you build in IB. WPF is the most recent addition and has lots of advantages but a somewhat steep learning curve.
This is probably oversimplified because VS does so much and I'm mostly familiar with the C# and C++/CLI capabilties. However it also supports Visual F#, Iron Python, Iron Ruby, Visual Basic, Sharepoint, Office Integration,Silverlight, XNA, etc.
Visual Studio is very extensible. There are lots of extensions to make it integrate with other tools. There are also a couple of extremely useful extensions that make refactoring and writing code easier, my personal favorite is ReSharper from JetBrains.
I'm curious about your thoughts on moving to a new IDE (specifically Eclipse). I have been hearing wonderful things about it from this community and I'm always on the lookout to try new things.
Currently I'm running Visual Studio 2005, with a bunch of external commands loaded (for compiling down to a binary, running lint, etc). We're developing C code for microcontrollers.
I've read over some of the other threads on here about the advantages and disadvantages to Eclipse and Visual Studio (specifically SO - best IDE thread and SO - best C IDE thread), but I'd like to hear your thoughts on using it for programming an embedded environment. I'd imagine that there is a simple way to use the external tools that Visual Studio currently uses (it simply calls various batch files that we've created).
Is it worth it to specifically switch over to Eclipse?
Answer to you question about way to call external tools: no problem - from eclispe you can anything: external program, batch file etc. Moreover, if you use custom build generator - you could use it transparent with eclipse.
I don't think I would switch from Visual Studio to Eclipse in hopes of getting a better IDE. Typically an embedded manufacturer makes plugins and toolchains that work specificially with Eclispe, that's what makes it worth using in the Embedded world. For example with the NetBurner plug-ins, when creating a new project you can just select New NetBurner Device Excecutable, or New NetBurner Library, all the default includes and libraries get set up for you and the proper cross platform tool chain is set up for you automatically. In the NetBurner case it also uses the Eclipse managed build process (as opposed to make files) which I find nice. There is also support for using make files if you prefer that option.
While I have a couple of tools set up to run as external tools (lint, an auto version updater, DOS prompt etc) most steps can be triggered from pre-build or post-build steps or there are many many add-ons for common needs like source code management, bug tracking, etc. There is great support for SVN, Trac and Mylyn for example. I use both VS2010 and Eclipse. I like them both but VS2010 is the better IDE. It's a little hard to compare because I do C# (and a little C++/CLI )in VS and C++ in Eclipse. That said, I wouldn't relish the though of trying set up VS to do my embedded tasks.