I read the previous posts - Tried a few things.
Here is the issue
A simple console OWIN self host app - Not much in there
public void Configuration(IAppBuilder appBuilder)
does not compile.
1. If I say using Microsoft.Owin and using Owin, then I get an error the using directive for owin already appeared. I can't figure out why.
2. If I do using Microsoft.Owin but modify the use as Owin.IAppBuilder
then the compiler says it can't find owin.IAppBuilder.
Yes I tried reinstalling Microsoft.Owin
and Owin (3 times)
I checked the project reference 4.5.1
Here is an issue to consider.
If your using statements are insider a namespace declaration
And your name space starts with Microsoft (for whatever reasons)
Then using Owin ==> looks at Microsoft.Owin
The solution is to use using global::Owin;
Related
I'm trying to learn how to develop my own enricher (I believe I do understand the basic, in terms of how enrichers relate to automation chains and so on). However, I'm having problems:
I can use existing enrichers with, for example,
Document.FetchByProperty and everything will work
But once I include my own custom enricher, I get the error (link below)
I couldn't figure out what I'm doing wrong, so I've took existing custom enricher from Nuxeo sample project, and got the same error
Any help is welcome!
Log link: https://answers.nuxeo.com/api/files/2b14d403-aa8a-4ac3-81ca-c9ee13623c2a
I've also asked the same question here:
https://answers.nuxeo.com/general/q/af5a6369c91942b5a81bf61549b467f2/Automation-and-a-custom-enricher
Make sure that you are compiling the enricher code with the same version of Nuxeo libraries as is the version of the target platform.
For example sample project is using the latest version (currently 11.1-SNAPSHOT) and the result code will not be compatible with Nuxeo platform 9.2. Especially abstract methods can have problems.
So there should be this section in pom.xml with <version>9.2</version> in your case:
<parent>
<groupId>org.nuxeo</groupId>
<artifactId>nuxeo-addons-parent</artifactId>
<version>9.2</version>
</parent>
The reason why the java.lang.AbstractMethodError is thrown here is in JsonGenerator. Nuxeo 9.2 uses org.codehaus.jackson.JsonGenerator while newer Nuxe versions use com.fasterxml.jackson.core.JsonGenerator.
Then this method signature (in 9.2):
public void write(org.codehaus.jackson.JsonGenerator jsonGenerator, DocumentModel documentModel) throws IOException;
... is not compatible with this (in 10.3 for example):
public void write(com.fasterxml.jackson.core.JsonGenerator json, DocumentModel document) throws IOException;
And Java is then not able to find correct write() method implementation and throws AbstractMethodError.
I am trying to follow this tutorial for Azure AD authentication in a .NET core web app:
https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/aspnetcore2-2
and I get this error:
The type or namespace name 'OpenIdConnectOptions' could not be found (are you missing a using directive or an assembly reference?)
I am using Linux and have no issue getting the basic templates to generate and build, the issue appears to arise where the tutorial says to add this line:
services.Configure<OpenIdConnectOptions>(AzureADDefaults.OpenIdScheme, options =>
{
options.Authority = options.Authority + "/v2.0/";
options.TokenValidationParameters.ValidateIssuer = false;
});
I have tried adding packages (semi randomly) e.g.:
Microsoft.IdentityModel.Protocols.OpenIdConnect
Microsoft.Owin.Security.OpenIdConnect
to no avail as the error persists and I get new issues like:
Error: Package 'Microsoft.Owin 4.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project.
I am not sure if I am missing some basics with authentication and running .net core on linux, I am new to this and just trying to get the ball rolling with a working demo that actually does something :)
I have not checked on linux yet, but the nuget package you are missing should be produced by ASP.NET Core from the following project: https://github.com/aspnet/AADIntegration. Did you try to update the latest nuget package of ASP.NET Core ?
As a workaround you might want to have a look at the following branch of the sample (which still has the code which was now moved to ASP.NET Core AADIntegration) : https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master
ran into the same issue. After installing these modules, it compiled.
In an Umbraco v6.1.6 I'm trying to get log messages from DotNetOpenAuth. Umbraco already comes with log4net, version 1.2.11.0 without a public key token. The Umbraco logs work fine, but I see no messages from DotNetOpenAuth. I also tried to add a second log4net.dll assembly, the one signed with the public key 669e0ddf0bb1aa2a, while also keeping the non signed one, but to no avail. Any ideas what could go wrong?
I have exactly the same setup and tried all manner of web.config redirects and log4net versions to no avail. The problem is Umbraco is built with an unsigned version of log4net. You have a few options here:
Try to get dotnetopenauth to use trace logging. It will default to this when it can't load log4net. I had problems determining if the trace logging was actually working or not.
Build your own version of dotnetopenauth - at least you'll be able to debug. Follow these instructions
I have a fairly stable server application version that's been deployed for nearly a year at dozens of customers.
One new customer recently setup the application and is getting the following error:
System.MethodAccessException: Attempt by security transparent method
[SomeMethod] to access security critical method [SomeOtherMethod]
failed.
Both SomeMethod and SomeOtherMethod are methods in assemblies that I wrote, that are built against .NET 4, and that are running inside a Windows Service. If it makes a difference, SomeOtherMethod does reference a type from a 3rd party assembly (EntLib 4.1) built against .NET 2.0. Looking at the code for EntLib 4.1, I do see that they use both SecurityTransparent and APTC attributes, but this has never caused issues at other clients.
These assemblies were upgraded from the .NET 2.0 CLR, but a long time ago. This exact code is running on other customers just fine, and I'm not explicitly using the APTC attribute nor am I using the SecurityCritical attribute anywhere.
This leads me to the conclusion that it's a configuration issue or perhaps .NET Framework patch issue. Has there been a patch released for .NET that would cause this breaking change? Is there a configuration setting some where that enforces this type of check which is off by default but that my customer may have enabled?
One last point. My service utilizes SSRS RDLCs to generate PDFs. Due to some changes in .NET 4, I must force the service to use the legacy security policy via the following config:
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true" />
</runtime>
For more details on why I need to do this, see this stackoverflow post: Very High Memory Usage in .NET 4.0
The important point is that I do this at all my other customers as well. Only this one customer is having issues.
Sigh, the patterns and practices employed by the Microsoft Patterns And Practices team that's responsible for the Enterprise libraries are pretty deplorable. Well, the exception is accurate, you cannot call a method that's decorated as "I'll definitely check security" from code that's decorated with "Meh, I won't check security so don't bother burning the cpu cycles to check it". Which scales about as well as exception specifications as used in Java. CAS is incredibly useful, but diagnosing the exceptions is a major headache and often involves code that you don't own and can't fix. Big reason it got deprecated in .NET 4.
Editorial done. Taking a pot-shot at the problem, you need to find out why CAS is being enforced here. The simplest explanation for that is that the service doesn't run in full trust. The simplest explanation for that is that the client didn't install the service on the local hard drive. Or is generally running code in don't-trust-it mode even on local assemblies, a very paranoid admin could well prefer that. That needs to be configured with Caspol.exe, a tool whose command line options are as mysterious as CAS. Pot-shooting at the non-trusted location explanation, your client needs to run Caspol as shown in this blog post. Or just simply deploy the service locally so the default "I trust thee" applies.
Editing in the real reason as discovered by the OP: beware of the alternate data stream that gets added to a file when it is downloaded from an untrusted Internet or network location. The file will get a stream named "Zone.Identifier" that keeps track of where it came from with the "ZoneId" value. It is that value that overrides the trust derived from the storage location. Usually putting it in the Internet zone. Use Explorer, right-click the file and click "Unblock" to remove that stream. After you're sure you can trust the file :)
I was facing the similar issue while running the downloaded WCF sample from http://www.idesign.net/ while using their ServiceModelEx library.
I commented out the below line in AssemblyInfo.cs in ServiceModelEx project
//[assembly: AllowPartiallyTrustedCallers]
and it worked for me.
In case it helps others i post my solution for this issue:
1) On the AssemblyInfo.cs, removed/commented the [assembly: SecurityTransparent] line.
2) The Class and the Method that does the actual Job was marked as [SecuritySafeCritical], in my case establishing a Network Connection:
[SecuritySafeCritical]
public class NetworkConnection : IDisposable
{
[SecuritySafeCritical]
public NetworkConnection(string networkName, NetworkCredential credentials)
{
.............
}
}
3) The Caller Class and Method was market as [SecurityCritical]:
[SecurityCritical]
public class DBF_DAO : AbstractDAO
{
[SecurityCritical]
public bool DBF_EsAccesoExclusivo(string pTabla, ref ArrayList exepciones)
{
....
using (new NetworkConnection(DBF_PATH, readCredentials))
{
....
}
}
}
In my case it was an issue when I managed a NuGet packages in the solution some package overrides System.Web.Mvc assembly version binding in main web site project. Set back to 4.0.0.0 (I had 5.0 installed). I didn't change notice the change because Mvc v4.0 was installed and accessible via GAC. Set back
I have been trying to get Moq (or rather Castle.Core) to create proxies for my internal types.
The following (when added to my project under test), allows things to work:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
However this (more secure version) does not:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=002400000480000094000000060200000024000052534131000400000100010077f5e87030dadccce6902c6adab7a987bd69cb5819991531f560785eacfc89b6fcddf6bb2a00743a7194e454c0273447fc6eec36474ba8e5a3823147d214298e4f9a631b1afee1a51ffeae4672d498f14b000e3d321453cdd8ac064de7e1cf4d222b7e81f54d4fd46725370d702a05b48738cc29d09228f1aa722ae1a9ca02fb")]
Note: the public key here differs to that documented here, I re-checked the public key of the Castle.Core.dll that ships with the current Nuget version of Moq.
Do I still have the wrong key?
[EDIT]
I have noticed the full Moq download from the official site (rather than Nuget) contains a NET40-RequiresCastle folder with a smaller dll, which implies that the Castle.Core code has been included in the default Moq.dll I guess.
I was looking at the Castle.Core.dll they provide for Silverlight and assuming they'd have used the same version throughout?
I know this is old, but for anyone who stumbles across this, I was having a versioning issue with Pex and Moq at one point, and wound up finding the most direct and useful approach to be the Strong Name Tool. That is, I found opened a Visual Studio command prompt and used "sn -Tp ThirdPartyAssembly.dll" to query it for the key directly. This proved a lot more efficient than perusing the internet looking for different, documented public keys to try out.