I am attempting to abstract some of our common WebApi bootstrapping logic into projects that all WebApis can reference. The general idea being that all the builder.Services.Blah() and app.UseOtherBlah() calls are standardised across our projects.
My assumption was that I would just create a class library and reference any assemblies I needed.
But I'm running into confusions due to the class library obviously not being a Web API project that's been all nicely set up for the web bootstrapping process.
The code below exists in a class library project as the only class. It is my attempt to abstract out the logging configuration. It doesn't do anything useful at the moment as I am just proofing the concept of abstracting this out into a class library.
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;
namespace XXXX.Hosting
{
public static class ExtendILoggingBuilder
{
public static ILoggingBuilder ConfigureLoggingProviders(this ILoggingBuilder logging, ConfigurationManager configuration)
{
// TODO: load providers from config
logging.ClearProviders();
logging.AddConsole();
return logging;
}
}
}
I need references (of some kind) to Microsoft.Extensions.Configuration and Microsoft.Extensions.Logging.
VS offers me the choice for Microsoft.Extensions.Logging between an assembly and a NuGet package.
But for Microsoft.Extensions.Configuration, I only get offered a NuGet package.
When I install the package, the dlls inside are not the dlls listed in the documentation page for the ConfigurationManager class here.
And I can't find the dll listed anywhere on my disk. Nor is it offered via NuGet.
My question is:
How do I work out a) what dll I need and b) where to get it from?
I don't really want a mixture of NuGet package references and assembly references. And I don't really want to reference anything I don't need to reference.
Related
I'm trying to start a Jersey/1.7 based project from scratch (as opposed to copying an existing project and adding new code on top, which is what my client normally does) in order to learn how stuff works. I'm stuck in a very early phase, trying to process a simple HTTP request:
package com.example.foo.view.rest;
import javax.ws.rs.Path;
import javax.annotation.security.RolesAllowed; // package javax.annotation.security does not exist
#Path("user")
#RolesAllowed("valid-users") // cannot find symbol
public class UserService extends BaseService {
public UserService() {
super();
}
}
I've copied these files from another project:
asm-3.1.jar
jackson-core-asl-1.9.2.jar
jackson-jaxrs-1.9.2.jar
jackson-mapper-asl-1.9.2.jar
jackson-xc-1.9.2.jar
jersey-client-1.17.jar
jersey-core-1.17.jar
jersey-json-1.17.jar
jersey-multipart-1.17.jar
jersey-server-1.17.jar
jersey-servlet-1.17.jar
jettison-1.1.jar
jsr311-api-1.1.1.jar
Project authentication works with Oracle SSO (Oracle Identity Directory).
The only javax.annotation.security.RolesAllowed I can find is an interface and I can certainly not see an actual implementation anywhere in my codebase. In fact the whole javax.annotation.security package is missing. I don't even know what library is supposed to provide it.
I'd appreciate any hint, no matter how obvious it looks.
javax.annotation is part of java, but not included directly in the jre.
It is not included in jersey.
You have to add this jar to your project for it to work.
I have set up a TestProject in Visual Studio for Mac that references my Xamarin Forms project for testing the non-visual portions of my code.
However I am getting the following error when I try to test a piece of my code that leverages Xamarin.Auth to access the keychain.
System.NotImplementedException :
Portable Bait And Switch is nuget feature, so the package must be installed in all project.
NotImplementedException will indicate that Portable Code from PCL is used and not Platform Specific
implementation. Please check whether platform specific Assembly is properly installed.
Cannot save account in Portable profile - bait-and-switch error.
Please file a bug in https://bugzilla.xamarin.com
This code works fine running on the iOS simulator, and I assume it has something to do with the way xamarin auth leverages the ios Keychain which is not present in this test project. I tried to add my ios solution in references, but I am unable to do so in "edit references" of my test project. The project references dialog wont permit it:
Here is the code that is failing in my PCL.
AccountStore store;
store = AccountStore.Create();
Apparently it has trouble with AccountStore.Create()
Here is the testcode class that calls the PCL:
using System;
using NUnit.Framework;
using CrowdWisdom;
using CrowdWisdom.Authentication;
namespace CrowdWisdomTest
{
[TestFixture()]
public class AuthServiceTest
{
[Test()]
public void SaveRestoreSecret()
{
String secret = "ABCD";
AuthService auth = AuthService.GetInstance();
auth.putSecret("MySecret", secret);
Assert.AreEqual(secret, auth.GetSecret("MySecret"));
}
}
}
Bait And Switch pattern that most cross-platform plugins use - is not a very unit-test friendly pattern. As you can see in your example.
My very first recommendation would be to use a contract based approach, alongwith with a dependency-injection container for your authorization process; so that you can provide a mock implementation as unit-test context. But if that is not possible, then you can use following hack to provide your own mock-switch for these static classes.
Basically, the error you see is because your portable code is accessing the portable version of Xamarin.Auth which is just intended to be the bait. So you will have to create your own implementation to act as switch in unit-test context (as they have done in platform specific libraries in Xamarin.Auth).
In order to do that, you will need to:
Create another portable library (which will only be used by your unit-test project). Let's say we name it Xamarin.Auth.Mocks. Make sure to update the root namespace, and assembly name as 'Xamarin.Auth' in its properties page.
Add a mock account store class and implement AccountStore using switch pattern.
namespace Xamarin.Auth
{
/// <summary>
/// A persistent storage for <see cref="Account"/>s. This storage is encrypted.
/// Accounts are stored using a service ID and the username of the account
/// as a primary key.
/// </summary>
#if XAMARIN_AUTH_INTERNAL
internal abstract partial class AccountStore
#else
public abstract partial class AccountStore
#endif
{
public static AccountStore Create()
{
return new MockAccountStore();
}
}
public class MockAccountStore : AccountStore
{
}
}
Add reference to Xamarin.Auth.Mocks in your unit-test library
Now every time you run your unit-tests, your portable code, will find your mock switch implementation for all their Xamarin.Auth needs, and you achieve true isolation from Xamarin.Auth; which technically is something we aspire to anyways when we write unit-test(s).
Note: If your portable code uses other bait-switch classes, add mock implementation for them too in your Xamarin.Auth.Mocks library. You only need to add mock classes for the ones that you use in your code; not all of the classes in Xamarin.Auth
I had the same issue, in my case the Xamarin.Auth version was the same (1.7.0) in all projects.
I solved the issue by editing the .csproj in this way:
<Reference Include="Xamarin.Auth, Version=1.6.0.1, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\packages\Xamarin.Auth.1.7.0\lib\MonoAndroid10\Xamarin.Auth.dll</HintPath>
<Private>True</Private>
</Reference>
Adding the tag <Private>True</Private> solved the issue for me.
The reference must be present and with this tag in .csproj files.
ASP.NET WebAPI has a much appreciated ability to discover ApiController classes in external DLLs even if those DLLs are not referenced. For example, I may have MyWebApiProject that has a set of ApiControllers. I could then create a completely separate project called MyApiProjectPlugin that contains ApiController classes also. I have been able to add the MyApiProjectPlugin.dll file to the bin folder with the first MyApiProject.dll and the original project will discover all the controllers in the plugin project. I really like that ability.
However, What I would like to do is be able to add the plugin project to a sub directory inside of the bin folder. Something like bin/plugins. When I tried this, the original MyApiProject was unable to discover the plugin's controllers.
Is there a simple way to get WebAPI to look for ApiController classes in the bin's subdirectories? If I can avoid rewriting a controller factory from scratch I would like to.
You can write an assembly resolver.
public class PluginsResolver : DefaultAssembliesResolver
{
public override ICollection<Assembly> GetAssemblies()
{
List<Assembly> assemblies = new List<Assembly>(base.GetAssemblies());
assemblies.Add(Assembly.LoadFrom(#"<Path>\MyApiProjectPlugin.dll"));
return assemblies;
}
}
In the Register method in WebApiConfig, register the resolver.
config.Services.Replace(typeof(IAssembliesResolver), new PluginsResolver());
hi i am having a different projects in my solution in the initial project (default project) i am accessing the global reference to App.xaml.cs in this way :-
App objref = (App)Application.Current;
But now i have added new project to my solution and trying to access the app.xaml.cs in the same way as defined earlier but i am not able to access app.xaml.cs ?
1)can i know the reason
2)What should i do if i want to use it in both the projects ?
Please let me know
Thanks in advance.
You can access it, but the new project will not be familiar with the derived App class that is in your project. To explain further we need to take inheritance into consideration.
There's a generic definition for the Application class that exposes a number of predefined methods. Your App.xaml.cs is a new class definition that is derived from the Application class. It has the methods it inherited plus what ever methods and properties that you've added. To make use of these any code that is seeking to use your extra properties or methods must have access to the class definition. Your classes in the other projects that you've added do not have access to this definition.
You'll need to make a class or interface definition that both projects have access to. There are several ways of organizing this. I'll present one.
Create your main project in the solution. This contains your
App.xaml.cs.
Create your class library project that contains the
other code.
Create a third project called Common that only contains
an Interface definition.
On the Interface definition define all of the methods/properties
that you want both your class library and main project to have
access too.
Have App.Xaml.cs implement this interface.
In the Class Library access var appReference =
(IMyInterfaceName)Applcation.Current. You'll have access to the
methods that were defined in the interface
I'm in the process of upgrading my application the latest release of Eclipse Equinox 3.7 and associated libraries. I'm excited to have the generic support in OSGi 4.3 and digging the new Bundle.adapt() concepts. I've run into one stumbling block.
Previously, I've used PackageAdmin.getBundle(Class) to find out which bundle loaded which classes. I have to do this due to some RMI object serialization usage.
QUESTION: Is there an way to accomplish the same result, mapping Class to Bundle, using the new BundleWiring API?
I realize that PackageAdmin is probably not going away anytime soon, but I hate deprecation warnings.
Kinda embarrassed that I didn't find this the first time I looked through the document. Answering my own question for completeness.
From the core specification PDF ...
Section 3.9.9 - Finding an Object’s Bundle
There are scenarios where a bundle is required in code that has no access to a Bundle Context. For this
reason, the framework provides the following methods:
Framework Util – Through the FrameworkUtil class with the getBundle(Class) method. The
framework provides this method to allow code to find the bundle of an object without having the
permission to get the class loader. The method returns null when the class does not originate from
a bundle.
Class Loader – An OSGi framework must ensure that the class loader of a class that comes from a
bundle implements the BundleReference interface. This allows legacy code to find an object’s
bundle by getting its class loader and casting it to a BundleReference object, which provides
access to the Bundle. However, this requires the code to have the permission to access the class
loader. The following code fragment shows how to obtain a Bundle object from any object.
ClassLoader cl = target.getClassLoader();
if ( cl instanceof BundleReference ) {
BundleReference ref = (BundleReference) cl;
Bundle b = ref.getBundle();
...
}
In an OSGi system, not all objects belong to the framework. It is therefore possible to get hold of a
class loader that does not implement the BundleReference interface, for example the boot class path
loader.