sensenet | touch simulator for deep reinforcement learning research | Machine Learning library

you have a previous version of sensenet and you upgraded the NuGet packages, am I correct? It seems that this combination does not work, because the component above is installed automatically by the new infrastructure - which is not compatible with your version. The only solution I see here is to downgrade the packages to their older versions (at least last August, maybe older). SenseNet has changed a lot since we moved to .Net Core, and there are some incompatibilities with the .Net Framework libraries. Please consider taking a look at the new "sensenet as a service" solution that will free you from the upgrade hassle.

This is by design: deny permission is always stronger than allow. So if you set explicit deny for a user, you cannot allow the same thing through a group. The time of setting the permissions or whether it is a group or user does not matter: the rule is that deny overrides allow.

This is why working with deny should be the last option. It is better to remove the allow permission for a user and than you can allow it through a group.

For details about breaking permissions, local permissions and the whole permission system in general, please visit this article.

SharedWidth is a reference field on every content in sensenet, that contains the list of users with whom the content is shared. So you can search by this field the same as by other reference field is sensenet queries.

For example if you want to search for the documents that are shared with the current user, add the following to the query:

As it is stated in the article that you've mentioned there's a more recent version of this install article in the community site here: http://community.sensenet.com/docs/install-sn-from-nuget Please use the docs on the community site for up-to-date info.

I think you need to reverse the reference direction. For example, the user works at a company, the company can have a profile. So the user can use a single reference field for targeting a company or the company's profile. This mechanism provides easy access in both directions: if you have the user instance user.Company or user.CompanyProfile returns the target object. Backward direction can be accessed with a simple query something like this: Content.All.OfType().Where(c => c.Company == company).FirstOrDefault().

The AddMember method of the group class expects either an IUser or an IGroup instance. The user you created previously is of the Content type, which is a wrapper type sensenet uses for everything. The underlying business object sits inside that content object, you can extract it using the ContentHandler property:

We think the issue was that we used the incorrect DateTime max value when inserting an object to the cache. The fix is already published in version 7.4.1 where we use the DateTimeOffset max value.

When the system starts it tries to initialize the logger component. In the default installation this is a simple event logger that tries to write events into the Windows Event Log - and if the appropriate log does not exist, it tries to create it on-the-fly. In some environments the application user does not have (Windows) permissions for this, which is normal.

You have multiple options:

• create the event log manually (see the createeventlog SnAdmin tool here)
• use a different logger that writes log entries somewhere else, not the Event log. For example there is the SnFileSystemEventLogger that writes entries to the file system. To configure the logger you may use the repository builder API in your MvcApplication:

```

you are correct assuming that this is related to that fix in .Net Framework. It happened in 4.7.2 as the binary serialization / type forwarding issue you have found suggests.

(more details on moving sensenet to .Net Standard can be found here)

We face the same issue in our Azure test environment and the reason is that 4.7.2 is not yet deployed to Azure App Service (or at least not everywhere). The original plan was for this to happen in September 2018 but they pushed it to October according to this issue.

This is not something we can control, so the solution is to

wait for Microsoft to deploy 4.7.2 to App Service

To check for the supported .Net Framework on your Azure environment please check this article.

What you have tried (deploying sn to Azure) is technically possible, everything you need is already published but there is no detailed guideline for that yet. We are working on it though.

In a super-small nutshell:

1. deploy the db (most likely by backup/restore) to Azure SQL Server.
2. configure messaging, because your app instances have to communicate with each other. In an on-premise environment we usually use MSMQ, but that is not available in the cloud, so we offer a RabbitMQ messaging provider for sensenet.
3. indexing: this is more complicated, because you'll have to spin up a VM for a centralized search service and install the service there.

The plan is that all this will be made easier and more straightforward in the future, but thanks for pioneering something new :).