dotnet/wpf · error · InvalidOperationException
SR.Format(SR.MemberNotAllowedForView, "AddNew")
Error message
SR.Format(SR.MemberNotAllowedForView, "AddNew")
What it means
ListCollectionView.AddNew is only legal when CanAddNew is true — i.e. the underlying collection supports adding (IBindingList/AddNew semantics or the collection is not read-only/fixed-size) and any AddNew transaction limit is respected. Otherwise it throws InvalidOperationException with MemberNotAllowedForView("AddNew").
Solutions
- Check CanAddNew before calling AddNew and disable the Add UI when it is false
- Make the underlying collection writable: use a List<T>/ObservableCollection<T> instead of a read-only or fixed-size list
- Provide a public parameterless constructor (or NewItemFactory) for the item type so the view can create instances
Example fix
// before
var newItem = (MyItem)view.AddNew(); // throws on read-only source
// after
if (((IEditableCollectionView)view).CanAddNew)
{
var newItem = (MyItem)view.AddNew();
}
else { /* disable add UI */ } Defensive patterns
Strategy: validation
Validate before calling
var ecv = (IEditableCollectionView)view;
if (ecv.CanAddNew)
{
var item = ecv.AddNew();
}
else { /* disable add feature or use a writable collection */ } Try / catch
try { var item = view.AddNew(); }
catch (InvalidOperationException)
{
// underlying collection does not support adding; surface to user
} Prevention
- Check CanAddNew before exposing Add UI in DataGrid or MVVM commands
- Back views with ObservableCollection<T>/List<T>, not arrays or read-only lists
- Ensure item types have public parameterless constructors when relying on AddNew
When it happens
Trigger: Calling AddNew() when the underlying IList is read-only or fixed-size, when a NewItemFactory/constructor is unavailable for the item type, or when the collection does not permit new items (CanAddNew false).
Common situations: DataGrid 'add row' feature bound to a read-only collection (e.g. a computed/frozen list, an array, or a list exposed without setters); MVVM code calling AddNew on views over immutable data.
Related errors
- SR.Format(SR.MemberNotAllowedForView, "AddNewItem")
- SR.Format(SR.MemberNotAllowedDuringAddOrEdit, "CustomSort")
- SR.Format(SR.MemberNotAllowedDuringAddOrEdit, "Filter")
- SR.Format(SR.MemberNotAllowedDuringAddOrEdit, "Grouping")
- SR.Format(SR.MemberNotAllowedDuringTransaction…
AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14).
Data as JSON: /api/errors/378d3cc5f81c9f72.
Report an issue: GitHub.
Appendix: source
Thrown at src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Data/ListCollectionView.cs:716
/// <summary>
/// Add a new item to the underlying collection. Returns the new item.
/// After calling AddNew and changing the new item as desired, either
/// <seealso cref="CommitNew"/> or <seealso cref="CancelNew"/> should be
/// called to complete the transaction.
/// </summary>
public object AddNew()
{
VerifyRefreshNotDeferred();
if (IsEditingItem)
{
CommitEdit(); // implicitly close a previous EditItem
}
CommitNew(); // implicitly close a previous AddNew
if (!CanAddNew)
throw new InvalidOperationException(SR.Format(SR.MemberNotAllowedForView, "AddNew"));
return AddNewCommon(_itemConstructor.Invoke(null));
}
/// <summary>
/// Add a new item to the underlying collection. Returns the new item.
/// After calling AddNewItem and changing the new item as desired, either
/// <seealso cref="CommitNew"/> or <seealso cref="CancelNew"/> should be
/// called to complete the transaction.
/// </summary>
public object AddNewItem(object newItem)
{
VerifyRefreshNotDeferred();
if (IsEditingItem)
{
CommitEdit(); // implicitly close a previous EditItem
}View on GitHub (pinned to 81131a70a4)