-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create v1.12 of generated libraries, with two PCL profiles #718
Conversation
Useful for debugging code generation.
Since NuGet doesn't currently filter libraries based on their supported target frameworks, these changes are necessary to ensure that `Install-Package Google.Apis.Storage.v1` still works in projects targeting .NET 4.0 now that new versions of the support libraries no longer target .NET 4.0. Profile259 supports newer frameworks and brings in the newest version of the support libraries. Profile328 is the "legacy" framework set and brings in the last version of the support libraries that supported Net40: v1.10, referred to here as oldCompatibleVersion for easier searchability. Updated GeneratedLibraries.proj so it will build both projects. Updated the .nuspec to include both built assemblies in the appropriate portable-xyz directories. Verified using test projects that the targetFramework values in packages.config and the HintPaths in the .csprojs are correct for the new project targets.
Private references are copied to the bin\ directory as part of build. That's useful when the directory will be copied for deployment; less so when we're only interested in adding the main assembly to a NuGet package. Setting `<Private>False</Private>` avoids unnecessarily copying hundreds of DLLs during the build.
Matt spent 5 (10?) minutes walking me through the changes, and the test PCL project. It'll trust that this does what we think it does. I'm fine with this going on, but could you add a Markdown file in the repository explaining our NuGet+TargetFx schenanigans? e.g. |
Will do. |
I didn't test it, but it seems like an elegant solution, thanks for fixing it so fast!!!! Thanks again Matt 👍 |
Verified you can install the package now targeting .net framework 4.0
I ran a dummy request using Oauth2 credentials (Didn't feel like testing everything else)
However I have a question: Lets say that my imba testing40 application now gets upgraded to .Net framework 4.5 that is after all what we are going to recommend people do. I set the project to framework 4.5 then run it. and it gives me errors
Doesn't seam to go and grab the 4.5 packages. Any one know how to upgrade the packages to the new framework? I am going to assume someone is going to ask this question on SO. |
After changing a project to target net45, I've used this command in the Package Manager Console to reinstall the NuGet packages, adding references to different assemblies as appropriate: |
Since NuGet doesn't currently filter libraries based on their supported
target frameworks, these changes are necessary to ensure that
Install-Package Google.Apis.Storage.v1
still works in projects targeting .NET 4.0 now that new versions of the
support libraries no longer target .NET 4.0.
Profile259 supports newer frameworks and brings in the newest version
of the support libraries.
Profile328 is the "legacy" framework set and brings in the last version
of the support libraries that supported Net40: v1.10, referred to here
as oldCompatibleVersion for easier searchability.
Updated GeneratedLibraries.proj so it will build both projects.
Updated the .nuspec to include both built assemblies in the appropriate
portable-xyz directories.
Verified using test projects that the targetFramework values in
packages.config and the HintPaths in the .csprojs are correct
for the new project targets.
Also fixed a few issues with generated library builds.