Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
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 have a .Net standard 2.0 project in a Visual Studio solution that contains some Azure functions. In the same solution, I've created a .Net Core 2.0 Unit Test project. I've added a project reference from the .Net Core Unit Test project to the .Net standard 2.0 library.
Despite the project reference, Visual Studio is behaving like I'm referencing a dll instead of the project. For example, if I try to use F12/Go to reference, it brings me to a 'From metadata' file instead of the actual code file in the other project. Additionally, codelens features like 'Tested by' (and even just 'referenced by') and the Live Unit testing icons in the .Net Standard project aren't working, since they don't seem to be aware of the Unit Test project at all.
Is there some way to get this integration working between the two projects? My Visual Studio is up to date (15.5.3 enterprise), and I'm not using any tools like Resharper or anything like that.
I'm also facing the same issue but so far the project reference vs dll reference is not the case. I believe this is an existing issue with Azure function projects. There is a thread in Microsoft community regarding this issue. The last comment from Visual Studio is as follows:
I'm closing this report, because in the last 90 days there was no internal developer activity and very small number of new votes or comments. Sorry, we would like to look at this further, but we just don’t have the time right now. Our goal in closing older issues such as this one is to keep customers informed on which issues are currently being pursued by Visual Studio teams. If you still have trouble with our latest version, please report it as a new problem.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.
I have a web solution that contains 5 class libraries and one asp.net web site project. It's an e-commerce solution that is compiled for .NET 3.5 (some class libraries are set to .NET 2).
When I got VS 2010 installed I decided to give a try and upgrading it to .NET 4 but that didn't go so well, can't remember why. I reverted the source code control, cleared all local files, re-downloaded from source control and went back to VS 2008.
I decided to give it another try with VS 2010 due to some issues with VS 2008 but when I build the solution it fails because one of the class libraries is compiling to .NET 4. I checked the project settings and it is set to .NET 2. I have tried doing a clean on the solution, that makes no difference, the project always builds the assembly to .net framework 4.x.
I imagine something is getting cached on the system, i.e. msbuild, etc. Does anyone know where to clear this cache so that whatever is holding my class library hostage to .net 4 can actually let it completely recompile and pick up the project settings again?
Thank you.
This was a problem in the project file having the Tools attribute set which just needed to be cleared for .NET 4 compilation.
When I change the target framework of any project in Visual Studio 2010 it does not actually change the System assembly references. For example if I target v2.0 and check the properties of System and System.Data I can see that they are still both v4.0. If i change the target to v3.5, System stays at v4.0 but System.Core changes to v3.5.
Because of this I am truly not targeting anything except v4.0.
There may be something strange in your install. I just created a WPF project, keeping the default settings, thus targeting .NET 4. Then, I switched to 3.5. VS asked to reload the project and then the targeted runtime of the references was v2 (correct) and their version was 3.5 (with an error that Microsoft.CSharp and System.Xaml were missing, which is understandable).
Then, I did the same for .NET 3 and 2 and got the same results: after reloading the project, the version of the referenced DLLs had changed were it made sense (System.Data is always v2.0).
When using the CLR v2, the vshost debug helper had its name changed to something like vshost-clrv2.
I've reinstalled Visual Studio several times and it hasn't solved anything. After uninstalling there is 10.0 stuff laying all over the place leading me to believe the uninstaller is also leaving what ever is causing this issue. I'm going to have to reinstall the OS to get the issue to go away.
I also wanted to link to my earlier post because this post has more information about how I originally discovered this issue, contains a link to the Microsoft Connect bug report I opened and links to several other users experiencing the same problem: Visual Studio 2010 Can no longer build .NET v3.5