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).
Related
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I work on a large system (10+ EXEs and 50+ DLLs). The entirety of this system was written in C++ up until around 2005, when we began migrating components to the .NET framework.
It would help our migration efforts tremendously if I could switch individual DLL projects to C++/CLI and provide both a legacy unmanaged API and a new managed API into the same DLL.
This approach worked when we first started, but then broke soon after. Visual Studio does not appear to support two C++/CLI projects linking to each other via the unmanaged API.
Is there any way to get this to work beyond the brute-force approach of adding export libraries from one project as content to another? That's what project dependencies are supposed to handle already.
Perhaps #pragma comment in the native header files would be useful. For that to work you need each project configured to write its generated import library into a common area that can be added to the library search path, but it saves you from having to manually add lib files as linker inputs, or as project content items. Also, it makes keeping release and debug library versions separate more easily, since you can just have a different search path for each configuration, instead of having to add each individual library twice to every single consuming project.
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.
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 working on a VS solution with 100+ projects in C#. I'm currently migrating it from VS 2008 to VS 2010. There is some work to be done because a lot of the projects use Enterprise Library 4 (which has to be upgraded to 5.0) and WCSF 2008 (which has to be upgraded to SCSF 2010). I'm going through the SCSF upgrade instructions, and one involves doing this:
Add a reference to the following
Service Location assembly in each
project that has a reference to an
Enterprise Library assembly.
Microsoft.Practices.ServiceLocation.dll
Is there any way to do this without going through the IDE? I mean, opening up each of 100-odd projects, then checking the references, then adding a reference if necessary, is one way of doing it, but is there a faster way? I was thinking along the lines of doing a search over the project files for a particular reference, then doing an insert if it was found.
If you've done this kind of thing before, suggestions would be very welcome. Thanks.
If you want to do this through the IDE, you can write a macro using VSProject.References to add/remove references as necessary.
However, C# project files (.csproj) are just XML, so you may be able to write a simple utility that can adjust the file as necessary using the standard XML classes.