| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixed bug #58244 - Error loading project - NuGetAuthoringPath item
already added
https://bugzilla.xamarin.com/show_bug.cgi?id=58244
Prevent the MSBuild property NuGetAuthoringPath being added twice
to the same dictionary by making the property provider thread safe.
|
|
|
|
This helps avoid unnecessary copy operations during the build.
|
|
|
|
Add accessibility attributes to the preferences dialog
|
|
[Ide] Allow New Project dialog to resize to fit text
|
|
Fixed bug #56918 - When typing a description in NuGet package Metadata
the UI keeps on growing
https://bugzilla.xamarin.com/show_bug.cgi?id=56918
In project options typing a long description for the NuGet package
metadata would cause the dialog to increase in width. The release
notes on the other tab does not have this problem. Setting the
scroll window's policy to never show the horizontal scrolllbars
seems to break the word wrapping. Leaving it as the default fixes
the wrapping so the dialog does not increase in width.
|
|
The left hand side of the project template wizard for the NuGet
package and multiplatform templates will now fit the content of its
labels and not be truncated if the text is too long.
|
|
|
|
[Core] Remove custom framework API
|
|
The IsDotNetProjectOnly condition is not correct because it is using
the project selected in the solution pad to check the type, and
that may not be the project for which the options dialog is being
opened. The right solution is to use the ItemType condition to
check the type.
This commit also includes a bump of Mono.Addins that fixes a bug
in Not conditions.
Fixes bug #55605 - [VSFM Preview 9] Solution option from IDE
toolbar doesn't open when cursor is set on project in solution explorer
(NuGet panel was incorrectly enabled in this context, and it was
crashing)
|
|
It's not useful to be able to define custom frameworks
inside MD, only MSBuild frameworks actually work now.
|
|
Fixed bug #52657 - Creating a new Multiplatform Library requires a
description
https://bugzilla.xamarin.com/show_bug.cgi?id=52657
Description is required when creating a NuGet package project or
a multiplatform project. To simplify the project creation process the
package id is used as the description by default. As you type the
package id into the project template wizard page the description text
box will be updated. The description can be changed to be different
to the package id if required.
|
|
Fixed bug #56706 - Can not create a nuget package with Standard net
libraries
https://bugzilla.xamarin.com/show_bug.cgi?id=56706
A NuGet packaging project that referenced a .NET Standard project
that used an Sdk style project would fail to build the NuGet package.
The build would fail with an error:
Error: Project targets '.NETStandard,Version=v1.4'. It cannot be
referenced by a project that targets 'NuGet,Version=v1.0'
Updating to the latest stable NuGet.Build.Packaging 0.1.276 NuGet
package fixes the problem.
See also https://github.com/NuGet/Home/issues/4858
|
|
If the generated .nuget.targets or .nuget.props are missing then
these are now created on opening the solution if automatic restore
is enabled.
|
|
Opening a previously created NuGet packaging project would show no
packages in the Packages folder. The problem was that the
PackageReference project item is exported by both the NuGet addin and
the Packaging addin. The NuGet addin's PackageReference project item
was used instead of the one defined by the Packaging addin so no
package references were available for the packaging project. Now only
one PackageReference project item type is exported and the packaging
project uses the one defined by the NuGet addin.
|
|
An obsolete overload of OnGetCanExecute was being overridden. Changed
the code to override the non-deprecated method instead.
|
|
Fixed bug #56701 - Windows created nuspec can not be loaded on a mac
https://bugzilla.xamarin.com/show_bug.cgi?id=56701
Visual Studio on Windows currently creates a .nuproj with no target
framework version which resulted in 4.0 being used by default. The
packaging project was explicitly checking for 4.5 or above. So the
packaging project now indicates it supports any target framework.
|
|
[A11y] Make the project options panels accessible
|
|
Adds label and help to most of the project options panels in the main repo. Panels using Xwt can't be
made accessible yet. Partially fixes #53537
|
|
Some tests fail on Linux because there's no MonoDroid or XamarinIOS
solution item there:
`MonoDevelop.Projects.MSBuild.UnknownSolutionItemTypeException : Unknown solution item type: XamarinIOS`
|
|
Fixed bug #55665 - NuGetizer adds NuGet.Build.Packaging version
0.1.157-dev but latest avail is 0.1.248
https://bugzilla.xamarin.com/show_bug.cgi?id=55665
Updated to the latest stable version of the NuGet.Build.Packaging
NuGet package available from nuget.org.
|
|
Roslyn 2.x needs this so we have to do it for MonoDevelop.Core
and every assembly that references it.
|
|
|
|
|
|
|
|
Fixed bug #51273 - Multiplatform library uses PCL Profile 78 instead
of Profile 111
https://bugzilla.xamarin.com/show_bug.cgi?id=51273
Switching from PCL profile 78 to 111 makes the project template
consistent with the standalone PCL project template.
|
|
|
|
Fixed bug #48249 - Add platform implementation. Create shared project
https://bugzilla.xamarin.com/show_bug.cgi?id=48249
Previously when right clicking a PCL project and selecting Add Platform
Implementation it was not possible to only select the Shared project
without selecting either iOS or Android. Now this is possible.
Selecting just the Shared project will create a Shared project and
a NuGet packaging project.
|
|
The Getting Started page was available for the shared project when
the multiplatform project template was created. The information on
this page is more relevant for creating mobile apps instead of
cross platform NuGet packages so for now it has been removed.
|
|
When adding platform implementations to a PCL project the Getting
Started page was added and opened to only the iOS project. Now the
Getting Started pages are disabled for all projects added when
adding platform implementations.
|
|
Fixed bug #47575 - Make PackOnBuild available in UI
https://bugzilla.xamarin.com/show_bug.cgi?id=47575
PackOnBuild can now be set to true in the project file from the UI.
PackOnBuild allows non-packaging projects to generate a NuGet package
on every build instead of having to use the Create NuGet Package menu.
There is now a check box in Project Options - NuGet - Build which
will set the PackOnBuild property in the .csproj file.
|
|
Fixed bug #47372 - NuGet Package template looks confusing
https://bugzilla.xamarin.com/show_bug.cgi?id=47372
The original problem was that a NuGet packaging project and a class
library project was created. The library project had a NuGet package
dependency. The library project was then referenced by the NuGet
packaging project and on building the NuGet package it contained
the library assembly and the NuGet package dependency assemblies
in its lib directory. It did not have the NuGet package as a
dependency in the .nuspec file. This is because the library project
needs the NuGet.Build.Packaging NuGet package installed for the
correct information to be added to the generated NuGet package. This
is confusing for a first time user.
Now when a reference to another project is added to a NuGet packaging
project then the NuGet.Build.Packaging NuGet package is installed
into that project if it is missing. This puts the referenced project
in the preferred state so that any NuGet package dependencies it has
are correctly added to the NuGet package generated by the NuGet
packaging project and only the library assembly is added to the lib
directory. Without the NuGet.Build.Packaging NuGet package
installed only primary outputs from the project can be collected
and package dependencies are ignored.
|
|
The project templates now explicitly define the directory where the
NuGet.Build.Packaging NuGet package will exist. This prevents the
install failing in NuGet packages since NuGet picks the first
package source from the primary sources, which in this case would
be all the local directories having NuGet packages defined by the
various addins, which may not have the NuGet package. NuGet would
then fail when it attempted to execute the package action since the
package source would not have the NuGet package. Using an explicit
package directory in the project templates for each package reference
avoids this problem since only that directory will be used as a
package source.
|
|
|
|
If automatic package restore is enabled then the NuGet.Build.Packaging
NuGet package will be restored to the global packages cache on
opening the solution if it is missing.
|
|
Restoring packages on a packaging project will restore the
NuGet.Build.Packaging NuGet package and also generate the
.nuget.targets and .nuget.props files needed to build the project.
The project builder is also reloaded to ensure that the new imports
are loaded otherwise the build will not generate the NuGet package
(.nupkg).
|
|
To make sure a NuGet packaging project can be built the
NuGet.Build.Packaging package needs to be installed into the global
machine cache. The first template the NuGet package project
template is installed a check is made to see if the package is
available in the global cache and if not it is installed there.
|
|
MSBuild imports are not generated when the NuGet.Build.Packaging
NuGet package is installed. These imports will import the MSBuild
targets for the NuGet.Build.Packaging NuGet package. The generated
imports are used by the NuGet.Packaging.Authoring MSBuild targets
that are included with the addin.
The NuGet.Build.Packaging NuGet package is now added to NuGet packaging
projects as a development dependency by setting PrivateAssets to All
for its PackageReference.
|
|
Removed the project.json file that was being added to new NuGet
packaging projects (.nuproj).
|
|
NuGet packages can be installed into a .nuproj project and a
PackageReference will be created in the project. Uninstalling a
NuGet package is also supported. This is available from the standard
Packages folder.
|
|
Updated to latest NuGet.Build.Packaging NuGet package 0.1.157-dev
instead of using the pull request based package.
|
|
|
|
Updated to NuGet.Build.Packaging 0.1.157-pr58 which has support for
reference assembly generation.
|
|
If a normal .NET project, not a NuGet packaging project, had NuGet
package metadata and referenced another project then the Create NuGet
Package command would not build the referenced projects before
generating the NuGet package. Now the command ensures referenced
projects are built before the NuGet package is generated.
|
|
When using the Create NuGet Package command on a NuGet packaging
project (.nuproj) the referenced projects would not be built. One
way to reproduce this is to create a new multiplatform project for
iOS and Android and then use the Create NuGet Package command on the
NuGet packaging project. The build will fail since the iOS and Android
projects are not compiled. This is because the Pack MSBuild target
is used which will only build the project it is being run on. Now
for NuGet packaging projects when the Create NuGet Package command
is selected a normal build is run for the project which ensures
referenced projects are built.
|
|
Updated to 0.1.44-dev.
|
|
Updated to 0.1.141-dev which fixes the problem where a NuGet
packaging project (.nuproj) referencing another .NET project with
NuGet package metadata was not adding the referenced project as
a dependency in its .nuspec file.
|
|
Added more target frameworks into the NuGet packaging project's
project.json file so it supports NuGet packages that support more
than .NET Standard 1.6. This is a workaround since the NuGet
packaging project should allow any NuGet package to be installed.
|
