.NET 4.6.1 or 4.6.2 seem to break IsInRole()

Upgraded application using IsInRole(), now only returns false (vb.net)

Read to the end before making code changes as there is a more obvious thing to check!
 
To support TLS1.2 for PCI requirements I was upgrading one of the applications to 4.6.1, after deployment behaviour controlled by our active directory groups was broken. It was like no one was a member of any AD groups anymore. First I thought it must be a coincidental screw up by someone in AD. It turns out it was something else…
 
The following code is used to check against a list of security groups to see if the current user belongs to any of them.
 
Public Shared Function IsInAdSecurityRole(RoleName() As String) As Boolean
Dim aName As String = Principal.WindowsIdentity.GetCurrent.Name
Dim aDomain As String = aName.Substring(0, aName.IndexOf("\") + 1)
AppDomain.CurrentDomain.SetPrincipalPolicy(
Principal.PrincipalPolicy.WindowsPrincipal)
For index = 0 To RoleName.Count - 1
If Thread.CurrentPrincipal.IsInRole(aDomain & RoleName(index)) Then
Return True
End If
Next
Return False
End Function

The code is ancient, has been in our applications for a very long time but on upgrading to .NET framework 4.6.1 it returns false for all roles. Checked casing and ran in debug inspection and yet failed to see why it stopped behaving as it always had before.
 
Unable to figure out what had happened and with a need to get systems running again I imported the namespace System.Security.Principal
then using the following method all seems well again.
 
Public Shared Function IsInAdSecurityRole(RoleName() As String) As Boolean
Dim currPrincipal As New WindowsPrincipal(New WindowsIdentity(Environment.UserName))
For index = 0 To RoleName.Count - 1
If currPrincipal.IsInRole(RoleName(index)) Then
Return True
End If
Next
Return False
End Function

I used this reference:

My.User.IsInRole() is not working after migrating to 4.6.2 framework in vb.net

 

Authentication mode in project settings Application-defined vs Windows

VB.NET has a setting in the project to say you wish to use application provided authentication method or use the default windows one. This was something that I had totally forgotten existed. It looks like the Authentication mode of the project got changed during the migration. Check the properties of the project, Authentication mode, see if changing it from Application-defined to Windows helps, it did in my case, bringing behaviour back to that which is expected.

 

2018-06-14_12-14-50

Change the drop down combo box to “Windows”

2018-06-14_12-23-38

 

Reference: https://social.msdn.microsoft.com/Forums/en-US/d00b65dd-61d8-4368-b2d2-eaedfc66af40/myusername-is-now-returning-empty-string?forum=vbgeneral

WCF Registered base address schemes are []

Moved WCF service from old server to 2012 server to find the WCF service would not run. It complained that

"Could not find a base address that matches scheme http for the endpoint with binding WebHttpBinding. Registered base address schemes are []"

Stack overflow post below was the lead as to how to resolve it:

WCF Registered base address schemes are [] error with https

With a fake IP address for purposes of this post, the WCF config section had the follow lines, removing the <add prefix… line from the .config brought the service to life.

<baseAddressPrefixFilters>
<add prefix="http://127.0.0.1/DataService/"/>
</baseAddressPrefixFilters>
 
So what is the baseAddressPrefix? –it is for dealing with where there are multiple IIS bindings for a site providing a listening filter for the service.

To quote MS documents:

“A prefix filter provides a way for shared hosting providers to specify which URIs are to be used by the service. It enables shared hosts to host multiple applications with different base addresses for the same scheme on the same site.+

IIS Web sites are containers for virtual applications which contain virtual directories. The application in a site can be accessed through one or more IIS bindings. IIS bindings provide two pieces of information: binding protocol and binding information. Binding protocol (for example, HTTP) defines the scheme over which communication occurs, and binding information (for example, IP Address, Port, Hostheader) contains data used to access the site.

IIS supports specifying multiple IIS bindings for each site, which results in multiple base addresses for each scheme. Because a WCF service hosted under a site allows binding to only one base address for each scheme, you can use the prefix filter feature to pick the required base address of the hosted service. The incoming base addresses, supplied by IIS, are filtered based on the optional prefix list filter.”

TF400409 you do not have licensing right to access this feature

Setting up a new user for team foundation server, although user has been added to all the licencing groups and project groups, they cannot expand the root node of the team collection. They can also not access the portal security pages as it gives the above error.

Turned out to be that they needed the access level for the user setting.

This is outlined within the document here: https://docs.microsoft.com/en-gb/vsts/security/change-access-levels

 

You may follow this route to the access level admin (in the version we use)

Select Security from the Team Explorer Settings menu from Visual Studio

2018-01-26_10-42-17

Navigate to the root of the control panel

2018-01-26_10-44-00

Navigate to the Access Levels tab

2018-01-26_10-46-10

 

Put the user under the appropriate access level of Basic or Advanced. This should then allow them to access the web portal without error and expand the source control collection node to see the individual projects (assuming you’ve set them up correctly with those too).

ClickOnce with report viewer control

Installing SSRS Report Viewer component for Visual Studio 2017 (VS2017) using NUGET

For Visual Studio 2017, the SQL server reporting services, report viewer component, for web forms or windows forms has been put into a NuGet package. This means it can be installed into projects where it is required, with the added benefit of no longer needing a client report viewer runtime msi installer for the client, that previously was used to install the runtime report viewer components into the GAC.

To upgrade a solution from using the old report viewer component, open all the references nodes in the project tree, remove all the old .dll references to the original report viewer .dll files. Then install the NUGET package for the projects in the solutions within the solution that require it.

To install the NuGet package, Right click the project, select Manage NuGet Packages,

Select the Browse option and then search for “ReportViewerControl” as shown.

2018-01-05_12-35-12

Take care to install the Windows Forms or Web Forms version as required and that it is the newer version, it is easy to click the wrong one as there are a few similar products in there.

This will pull down the required .dlls in to the project.

If you need the control in the visual control toolbox, then right click the toolbox area, select “choose items”, then in the .NET Framework Components Tab use the Browse button to browse to the control’s dll. This will be located in the “\packages\Microsoft.ReportingServices.ReportViewerControl.Winforms.140.1000.523\lib\net40” folder for the example where we installed the version shown above (note the version number). The packages folder is usually found with the solution or project files somewhere.  Select the file “Microsoft.ReportViewer.WinForms.dll” within that folder.

This will add the control to the toolbox.

2018-01-05_12-41-26

 

Problems:

I experienced some real problems after this when trying to deploy the application with the ReportViewer control via ClickOnce deployment.

On install of a non-developer machine, various errors occurred.

These were due to the “Microsoft.ReportViewer.Design.dll” library being referenced by the project. This meant the project then had visual studio dependencies introduced. Removing this file caused the application deployment to work again as expected.

"assembly Microsoft.VisualStudio.Text.Logic version 14.0.0.0 be installed in the GAC"

The above was caused by the report viewer design dll being referenced by the project, causing a dependency that was picked up by the ClickOnce manifest generator.

Microsoft.VisualStudio.Text.Logic installed in teh Global Assembly Cache

Assembly Microsoft.VisualStudio.Diagnostics.Assert needs to be installed in the Global Assembly Cache

image

Unable to install or run the application. The application requires that assembly Microsoft.VisualStudio.Diagnostics.Assert Version 14.0.0.0 be installed in the Global Assembly Cache (GAC) first.