I've downloaded the source code, converted the solution to VS10 format, fixed all compilation errors (mainly deleted references to .NET 3.5 versions of System.Web.Routing and System.Web.Abstractions and added .NET 4 versions in their places) and compiled the project.
But when I add a reference to one of the output assemblies (in this case MVCContrib.TestHelpers.dll) from it's output directory (/bin/Release/) and check the referenced assembly's properties in VS it still says that the runtime version is 2.0. Why?
Altough I'd like to be able to build the source myself, in case I want to add or change something, it would also be useful to know if there was an "official" .NET 4 build out there, that I've been unable to find.
Here are the steps you need to take to convert MVCContrib to target .NET 4:
Open the MVCContrib solution in VS2010 to trigger the project upgrade wizard
Change all projects to target .NET 4 (go to each project's properties and in the Application sheet change the Target Framework property)
Go through all projects and remove all references to System.Web.Routing and System.Web.Abstractions. Now readd references to these assemblies using the Add Reference dialog. This will force them to be the 4.0 version.
It looks to me like you might have missed step #2.
Since .NET 4 introduces a new CLR (see here and here) you indeed need to see a runtime version of 4 specified there. Perhaps you didn't compile this as .NET 4? Try looking at your local MVCContrib's properties to make sure it compiles on top of the v4 of the CLR. (Yes, I've read you saying you changed).
Or, stating the obvious, you weren't looking at the right assemblies? those DLLs shouldn't be accepted at a non-v4 projects, so how did you see "v2.0" in a compiling project?
Related
I'm building a solution containing .NET Standard 2.0 and .NET Core 2.0 projects (C# and F#) in VS2019 (16.1.1). If I build multiple times without changes the second and subsequent builds should say "Build: 0 succeeded, 0 failed, X up-to-date", but it sometimes rebuilds some projects every time. How do I find out exactly why?
There are many SO questions and blog posts about this, most of them suggesting setting the build log verbosity to "Diagnostic" and looking for "not up to date". I've done that and the string is not found, nor is "not up-to-date" (but "up-to-date" occurs many times). So this appears to have changed in VS2019. I also know about the U2DCheckVerbosity registry setting, but that's only for .NET Framework. Reading through the build log output is unrealistic, as it's over 360 thousands lines, so I need to know what to search for.
Please note, I'm not looking for guesses as to what the problem might be - I'm looking for a way to get VS/the compiler to tell me.
I'm looking for a way to get VS/the compiler to tell me. (For VS2019)
It's hard to reproduce same issue so I'm not sure about the cause of your issue. But as for what you're asking is the way to find up-to-date related info in Output window, maybe you can check the Up To Data Checks option for .net core.
Go Tools=>Options=>Projects and Solutions=>.net core=>Up To Data Checks. Make sure you've checked the Don't call MSBuild if a project appears to be up-to-date. Then change the Logging Level to Info or Verbose.(Choose the suitable level according to your needs)
For the normal .net framework projects or C++ projects, the build output verbosity in build and run would be of great help. But when trying to find the reason why VS consider one .net core or .net standard project is out-of-date, I think we can try this option since its output is more clear.
E.g: (One .net Core project which depends on the Standard project with Info level .net core Up-To-Date Check):
And if you have too many projects in one solution, I suggest you build one project one time instead of build the whole solution so you can locate the cause of the rebuild more easily.
VS writes a file called NETCoreApp,Version=v2.0.AssemblyAttributes.cs into temp folder. If you build several .net core projects, the file gets changed by the other project and your VS thinks the old project is modified and builds it.
Move the generated files into the project to reduce the builds:
<PropertyGroup>
<TargetFrameworkMonikerAssemblyAttributesFileClean>False</TargetFrameworkMonikerAssemblyAttributesFileClean>
<TargetFrameworkMonikerAssemblyAttributesPath>$(MSBuildThisFileDirectory)SharedAssemblyAttributes.cs</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>
In VS2019 the option to control logging is:
The default is "None", but honestly "Minimal" is a good setting in general. When set to that level, only a single line is output per project, and only if that project is not up-to-date. That line will explain exactly why the project is considered out-of-date.
It's worth remembering that this is Visual Studio's up-to-date check, which it uses to quickly assess project state and avoid the comparatively expensive call to MSBuild. It is possible, with exotic project configurations, that VS determines your project needs building, but MSBuild doesn't actually build. This is rare, but can be worth understanding if you're debugging issues here.
I'm creating a kind of big project, that will interact with a family of programs (for now, CorelDraw but in the future could also work with InkScape, maybe Illustrator) and maybe as a stand-alone.
For this I separated my solution in many projects:
- one for WinForms UI,
- another for the Domain Model,
- another for a specific version of Corel Draw
So, since I'm still learning C# (and the tools - VS2017 community) I chose WinForms because it was closer to the VBA I'm already familiar with, but in the future I intend to maybe move to WPF, or some other UI (the domain could be used for a mobile app or website for instance).
Also regarding the specific version of Corel Draw, I'm starting with the one I use at work but in the future I will add other projects for the interaction with each version. More specifically, a project each to generate the .dll(s) each version of Corel Draw expects to start the plug-in. Or another project for the .dll InkScape expects, or even the Main exe if I choose to make a standalone app.
So in short: how can I save different "profiles" for the compiler to know which projects to compile and which to not compile, and set a different "build path" for each (so when I make the installer for each kind of build, I have all the necessary files that build needs to work correctly)?
With your solution open, "Solution Explorer"->right-click your solution (at the top of the window)->"Properties"->"Configuration Properties"->"Configuration".
Then click "Configuration Manager", then "Active Solution Configuration"->"New...".
This creates a new configuration. You can now select how/if the various projects should build for that configuration. (You can also use this same window to edit how existing configurations build).
Also you can consider making an entirely different solution if you're fundamentally building a different thing (this is likely to be easier than ending up with 30 build configurations for one solution)
Also, you can get at the configuration name in your projects via the $(ConfigurationName) macro. It's good to make sure your projects can build without this being set properly, though (so that they aren't dependent on a particular solution)
I try to use Xcode (v.7.3.1) for my C++ project (build system - make), but the experience is quite poor (and it was always like that since old versions like v4 when I started using it) - code completion doesn't work, color syntaxing works oddly (no coloring sometimes, or partially colored code), no "jump-to-definition" functionality, can't switch b/w header/source files with shortcuts. Basically, it's just a text editor where I have to use "Find" and Cmd+Shift+O all the time.
Is this intentional and Xcode will never get any proper support for C++ projects with external build system (make) or am I misconfiguring my project? How can I re-index files in the project? How can I make code completion work?
Thanks,
I believe there is a way to use Xcode with makefiles by adding an external build target, file->new->target->External Build System.
This is an older tutorial but the steps may be worth looking through: http://web.ist.utl.pt/jose.alberto.coelho/mac/MakefilesXcode.pdf
I've never had a problem with the syntax highlighting, but I remember the refactoring support being limited for C++ in some ways.
So, I ended up using this workaround: even though, I use external build system, I create Console Application project in Xcode and choose C++ language in settings. Then, I simply add my source files to the project (just drag folders from the Finder window) and then manually create project targets of type External Build System as I need. I don't use default target and don't use generated main.cpp file at all.
My files get indexed with no problems. I'm also able to debug code as I used to.
I still think Xcode developers should review indexing process for the projects with external build system...
Thanks for all the insights though!
I'm building a Ruby C Extensions and I have to build for both Ruby 1.8 and Ruby 2.0. The source code is the same, but I have to link to different Ruby libs and set different build paths.
In Xcode I was able to set up a project where the project contained the common configuration. Then I set up two targets that configured different include paths and libs as well as different output (Debug/Release) paths.
When I build I will get two products built, one for each targeted Ruby version. When I build Release I get:
build/Release/1.8/Example.bundle
build/Release/2.0/Example.bundle
Now I am trying to do the same thing for Visual Studio 2010. I've been looking at the Configuration Manager and Property Sheets, but I'm struggling to fond out how I can make the same type of inheritance for the targets as I can in Xcode.
Is it possible to have multiple targets in VS, as you can in Xcode, that produce two products from the same project when you build?
Do I have to create a Debug and Release configuration for each Ruby core I want to target?
I think I know what you are looking for (but I can't be sure, as I have no experience with Xcode.)
If you are using Visual Studio, one way you can do something like this is to set up you project properties for a build configuration (e.g. for Release) and then copy that config into a new build type (e.g. call it "Release20") and go in and change the properties that you want for the new build. You can do this in "Configuration Manager". (When you select to add a new configuration, it lets you copy all properties from an existing one.)
However, it seems that you are already familiar with this, so I'm not sure what the problem is.
Another thing you should know is that the two build configs don't stay linked together (this is not a proper inheritance and overriding of properties, like using property sheets.) If you change something in one, it doesn't affect the other.
Precisely for these reasons (in addition to some others) I myself have foregone trying to wrangle the VS build system. I now use Premake and CMake for all my projects. But of course it's quite a chore building a build system for someone else's large code base.
I am currently migrating a reasonably large solution from VS2008 to VS2012. To date, this solution has been dependent on a command line build for several build steps, and I want to use the project system properly to execute these build steps. I've been through the various options and decided that a custom build step makes sense in most of the VC++ projects that require it. The solution is a mix of C++, C# & VB.
These tasks include building Primary Inter-op Assemblies and processing output files using third-party utilities, where the input and the output are the same.
I've had some teething issues, but I'm mostly up and working with this approach. The remaining issue is one of deploying these additional outputs to dependent projects.
Consider this; I have a third-party component, which given an input of a.dll produces two outputs, a revised a.dll and a_util.dll. When I have a project that is dependent on a.dll, I now need that project to pull a_util.dll in to it's output too. I was hopeful that the "Treat Output as Content" field on the custom build step in VS2012 would help in this respect, but I'm going by the one-liner in the UI, I can't find any comprehensive documentation on this option. In fact, the MSDN documentation just pretends this option doesn't exist.
If anyone can help explain this option, or an alternative approach, that would be great.
EDIT
At the moment, I am adding a BeforeBuild target to each dependent project to copy the additional outputs into that dependent project. The problem with this approach (while it works) is one of maintenance. Unfortunately if a dependency of this type is missed, it results in a cryptic runtime error.
Here's a link to VS2013 documentation that says:
Treat Output As Content: This option is only meaningful for Windows Store or Windows Phone apps, which include all content files in the .appx package.