Develop Reference

IBM.Data.DB2.Core error in new DB2Connection(connectionString)

We have the IBM.Data.DB2.Core (3.1.0.300) nuget package installed in our .netstandard2.1 application library, to connect to an external DB2 instance on prem.
On running the following code from a .net core azure function v3 Windows 64bit (from a netcoreapp3.1 project)
var connectionString= "Server=DB2_IP:DB2_Port;Database=DB2_DBNAME;UID=DB2_UserId;PWD=DB2_Password;"
var connection = new DB2Connection(connectionString);
(note the values in the connection string are placeholders for anonymity)
We are receiving the following error
IBM.Data.DB2.Core.DB2Exception (0x80004005): ERROR [58005] [IBM][DB2.NET] SQL0902 An unexpected
exception has occurred in
Process: 21308 Thread 33 AppDomain: Name:Microsoft.Azure.WebJobs.Script.WebHost
There are no context policies. Function: AESEncryptADONET (Encryption Info)
CallStack: at System.Environment.get_StackTrace()
at IBM.Data.DB2.Core.DB2ConnPool.HandleUnknownErrors(String strFncMsg, Exception exception, Boolean bThrow)
at IBM.Data.DB2.Core.DB2ConnPool.EncryptString(String value)
at IBM.Data.DB2.Core.DB2ConnPool.ReplaceConnectionStringParms(DB2Connection connection, String szValue, DB2ConnSettings& pSettings, DB2ConnSettingsInternal& pSettingsInternal, Boolean bAttach, Boolean pushDownStrAppended)
at IBM.Data.DB2.Core.DB2Connection.set_ConnectionString(String value)
at IBM.Data.DB2.Core.DB2Connection..ctor(String connectionString)
Does anyone have any idea where we're going wrong, or alternatively have a coherent end-to-end guide on the setup that may give me a clue.
All documentations I have found thus far has been rather sparse and a little inconsistent.

SharePoint 2010 Web Part Error - Exception from HRESULT: 0x80131904

A client of ours recently encountered a problem with a web part I wrote a while back. This web part is an advanced search which returns results based on information entered into a text box and the criteria selected from a drop down. This web part has been functional on other customer sites and the error which is now encountered by this one client could not be replicated, even after extensive testing on our development environment. This error only appears when the search column is a lookup field and works as expected on any other field type. I have looked around the web to find a resolution specific to my problem, but the majority of the cases refer to an SQL error of the Content Database being out of space, which I don't believe is the case in my instance.
Below is the full stack trace message we receive. Any help to resolve this problem would be very much appreciated!
Exception from HRESULT: 0x80131904 at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
at
Microsoft.SharePoint.Library.SPRequest.GetListItemDataWithCallback2(IListItemSqlClient
pSqlClient, String bstrUrl, String bstrListName, String bstrViewName,
String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags,
ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback,
ISPDataCallback pPagingPrevCallback, ISPDataCallback
pFilterLinkCallback, ISPDataCallback pSchemaCallback, ISPDataCallback
pRowCountCallback, Boolean& pbMaximalView) at
Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData() at
Microsoft.SharePoint.SPListItemCollection.GetEnumerator() at
Biz_AdvancedListSearch_Module.AdvancedListSearch.AdvancedListSearch.btnSearch_Click(Object
sender, ImageClickEventArgs e)
EDIT: The problem only arises when the lookup column uses the "contains" search criteria. I use CAML Queries to retrieve the data and using a console application, I determined that this was definitely possible with a lookup field.

A little old, but I had the same issue today. The comparers are case sensitive. should be . In my case, it was , changed to and it works now!

Does LibGit2Sharp support cloning a repository from the local file system?

I am trying to clone a git repository from the local file system:
using System;
using LibGit2Sharp;
class Program
{
static void Main()
{
var sourceUrl = #"file:///c:/work/libgit2sharp";
using (Repository.Clone(sourceUrl, "targetDir", bare: true))
{
Console.WriteLine("repository successfully cloned");
}
}
}
and I get an exception:
Unhandled Exception: LibGit2Sharp.LibGit2SharpException: An error was raised by libgit2. Category = Odb (Error).
Failed to find the memory window file to deregister
at LibGit2Sharp.Core.Ensure.Success(Int32 result, Boolean allowPositiveResult) in c:\work\libgit2sharp\LibGit2Sharp\Core\Ensure.cs:line 85
at LibGit2Sharp.Core.Proxy.git_clone_bare(String url, String workdir, git_transfer_progress_callback transfer_cb) in c:\work\libgit2sharp\LibGit2Sharp\Core\Proxy.cs:line 219
at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, Boolean bare, Boolean checkout, TransferProgressHandler onTransferProgress, CheckoutProgressHandler onCheckoutProgress) in c:\work\libgit2sharp\LibGit2Sharp\Repository.cs:line 431
at Program.Main() in c:\work\ConsoleApplication1\Program.cs:line 10
I've also tried the following source url:
var sourceUrl = #"c:\work\libgit2sharp\.git\";
and got another exception:
Unhandled Exception: LibGit2Sharp.LibGit2SharpException: An error was raised by libgit2. Category = Config (Error).
Failed to parse config file: Unexpected end of file while parsing multine var (in c:/work/ConsoleApplication1/bin/Debug/targetDir/config:23, column 0)
at LibGit2Sharp.Core.Ensure.Success(Int32 result, Boolean allowPositiveResult) in c:\work\libgit2sharp\LibGit2Sharp\Core\Ensure.cs:line 85
at LibGit2Sharp.Core.Proxy.git_clone_bare(String url, String workdir, git_transfer_progress_callback transfer_cb) in c:\work\libgit2sharp\LibGit2Sharp\Core\Proxy.cs:line 219
at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, Boolean bare, Boolean checkout, TransferProgressHandler onTransferProgress, CheckoutProgressHandler onCheckoutProgress) in c:\work\libgit2sharp\LibGit2Sharp\Repository.cs:line 431
at Program.Main() in c:\work\ConsoleApplication1\Program.cs:line 12
targetDir is never created.
If on the other hand I use HTTP transport, the Repository.Clone method works fine:
var sourceUrl = "https://github.com/libgit2/libgit2sharp";
So my question is if I am doing something wrong or if this is unsupported feature or a bug in the native git2.dll?

So my question is if I am doing something wrong or if this is unsupported feature or a bug in the native git2.dll?
A bit a both, actually.
The first exception is clearly a bug. This should not happen and will be troubleshot.
The second one requires a deeper analysis. Would you be so kind as to open a issue in the LibGit2Sharp project?
Good news are that a pull request from BenStraub was recently merged. This pull request implements the local fetch transport which should pretty solve the issue.
LibGit2Sharp will be updated in the following days with a new a new version of libgit2 binaries which should allow you perform a local clone/fetch. I'll update this answer as soon as it's been done.
Update
This test shows how do to a Clone and a Push over against a local repository.

Active Directory custom attribute can not be seen by it's owner on some computers

A added a custom attribute to the Active Directory Schema. On one machine when I try to query the attribute I get errors back from my code.
Here is the C# version to test this out.
static class Program
{
static void Main()
{
Console.ReadLine();
DirectoryEntry directoryEntry = (DirectoryEntry)UserPrincipal.Current.GetUnderlyingObject();
//Execption on this line
var allowedDatabases = directoryEntry.Properties["vwDBAccess"];
foreach (var record in allowedDatabases.OfType<String>())
{
Console.WriteLine(record);
}
Console.ReadLine();
}
}
System.Runtime.InteropServices.COMException was unhandled
Message=Unknown error (0x8000500c)
Source=System.DirectoryServices
ErrorCode=-2147463156
StackTrace:
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at Sandbox_Console.Program.Main() in C:\Users\srchamberlain.VW\documents\visual studio 2010\Projects\Sandbox Console\Sandbox Console\Program.cs:line 16
InnerException:
The Error Code 0x8000500c represents E_ADS_CANT_CONVERT_DATATYPE. This only happens on one machine. I have 3 other computers (all part of the same domain as the first computer) and those behave correctly when running the exact same code for the exact same user and give the the content of the attribute. Also if I run as a different user, on the same box, but query the bad user's attributes I can pull up the information correctly when connecting as another user.
I have tried refreshing the schema on the box using the technique from this KB article but the issue is still happening.
What is going wrong on this one computer?
Clarification:
vwDBAccess is a multivalued string, so when it works directoryEntry.Properties["vwDBAccess"] return a string with there is one item, sting[] when there is more than one, and null when there are no items. This account has 3 items set. When I run as a different user and query the bad user I correctly get string[3] returned.

Typically if something is only happening on one machine in a network then it boils down to service pack and update levels of the OS or interaction with other software on the system (A/V is the worst offender).
The first thing I would do is look at the SP and updates applied to the working machines, then compare that to the non-working one. You should see one of two situations:
If the working machines are more up to date, then apply whatever updates are necessary to the non-working machine.
If the working machines are less up to date, then update one and see if it starts failing. If that's the case, you might need to contact MS.
My gut says that the non-working machine is simply out of date.

Querying custom LDAP property via System.DirectoryServices in C#?

I have a custom LDAP schema installed on my OpenLDAP server which is as follows:
attributeType ( 999.0.01
NAME 'picturePath'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectClass ( 999.1.01
NAME 'indieStackTeam'
DESC 'Team definition for IndieStack'
SUP groupOfUniqueNames
STRUCTURAL
MAY ( picturePath )
)
In my ASP.NET MVC 2 application, I'm querying for the picturePath property like so (and it is confirmed that picturePath exists in the list of keys):
this.Picture = properties["picturePath"].Value as string;
When I attempt to do this under .NET 3.5 I get the following exception:
[COMException (0x8000500c): Unknown error (0x8000500c)]
System.DirectoryServices.PropertyValueCollection.PopulateList() +347013
System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) +49
System.DirectoryServices.PropertyCollection.get_Item(String propertyName) +150
However, when the same code runs under Mono (on the same server as OpenLDAP) it works perfectly fine. Clients such as LDAPAdmin can also read the picturePath property correctly.
More so, it's only when I go to read the value that it fails; I can see the property is there in the keys list, I just can't access it.
Unfortunately unknown error doesn't tell me a lot about what's going wrong, but I'm finding the .NET implementation of System.DirectoryServices is very flaky (you get the same unknown error if you connect to the LDAP server using lowercase in 'DC=').
Has anyone had this problem before and if so, how is it solved?

Two things you should check:
1) does that particular user object indeed have a value in picturePath? You might want to check for existance of the property before accessing it:
if(properties.Contains("picturePath") && properties["picturePath"].Count > 0)
{
....
}
2) If I remember correctly, to get access to custom attributes, you should explicitly refresh the cache for a user object before doing anything:
DirectoryEntry de = ......; // find / assign that DirectoryEntry somehow
de.RefreshCache(); // to load all properties from the directory
or:
de.RefreshCache(new string[] { "picturePath" }); // to just load the "picturePath" attribute
Also: the classes in System.DirectoryServices are really mostly geared towards being used against Active Directory - there might be "surprises" or subtle incompatibilities when used against some other LDAP server - like OpenLDAP.

It seems that the .NET LDAP client expects a correctly formed OID for attribute types and object classes.
You'll note that I was using OIDs of the form 999.X.YY, which while they might be syntactically correct, aren't usually encountered in the real world. My guess is the LDAP client parses OIDs and since these don't conform to what is expected, it throws an error.
I changed the OIDs to 1.3.6.1.4.1.40000.1.3.1 and 1.3.6.1.4.1.40000.1.4.1 respectively (I've also applied for a PEN, which will give me an assigned number instead of '40000'), refreshed the schema in the server and recreated the entries and the LDAP client now correctly reads the custom attributes.