we have source code from a long time ago .NET 2.0 which looks like:
DirectoryCatalog catalog =
new DirectoryCatalog(Path.Combine(Path.Combine(applicationDirectory, providersDirectory), providerSubdirectory));
CompositionContainer container = new CompositionContainer(catalog);
CompositionBatch batch = new CompositionBatch();
batch.AddPart(this);
batch.AddExportedObject(container);
container.Compose(batch);
This has worked fine for years, but after upgrading visual studio and the framework to .NET 4.0, the call to AddExportedObject no longer seems to be supported by MEF.
As you can read here,
While CompositionBatch itself does not contain an AddExportedObject<T>
there is an extension method for it. The extension methods are in the
root System.ComponentModel.Composition namespace so ensure you are
including that in your file's using statements. If you cannot get the
extension method to work you can always call the method directly on
AttributedModelServices.
Related
There was a version of Leaf that I was using to load .html files instead of .leaf ones from my Vapor project, which would make syntax coloring for those same files done automatically.
The version of Leaf was 4.0.0-tau.1 and the one for LeafKit was 1.0.0-tau.1.1
When using this particular version, I could setup leaf in the configure.swift file this way:
/// Change the classic .leaf extension to .html for the syntax
/// coloring option of Xcode to work each time the app is being load up.
fileprivate func leaf(_ app: Application) {
if !app.environment.isRelease {
LeafRenderer.Option.caching = .bypass // Another issue from the update
}
let detected = LeafEngine.rootDirectory ?? app.directory.viewsDirectory
LeafEngine.rootDirectory = detected
LeafEngine.sources = .singleSource(
NIOLeafFiles(fileio: app.fileio,
limits: .default,
sandboxDirectory: detected,
viewDirectory: detected,
defaultExtension: "html"))
app.views.use(.leaf)
}
In this code, the LeafRenderer.Option.caching = .bypass and the code used with LeafEngine do not work anymore since having updated Leaf to 4.1.3 and LeafKit to 1.3.1.
How can I successfully make this code work as before with the updated Leaf and LeafKit frameworks?
You can use this Xcode plugin:
https://github.com/OmranK/VaporLeafPlugIn
It adds Vapor Leaf language support to Xcode IDE. Provides syntax highlighting for Leaf tags as well as HTML tags with auto-indentation all together.
At the moment the plugin supports Xcode up to 13.2 beta. Future Xcode versions will require small update (add new DVTPlugInCompatibilityUUID) but it can be easily handled even on already installed plugin.
I'm trying to query QBO for, among other entities, Accounts, and am running into a couple of issues. I'm using the .Net Dev Kit v 2.1.10.0 (I used NuGet to update to the latest version) and when I use the following technique:
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
IEnumerable<Intuit.Ipp.Data.Qbo.Account> qboAccounts = cquery.ExecuteQuery<Intuit.Ipp.Data.Qbo.Account>(context);
(i.e. just create a new AccountQuery of the appropriate type and call ExecuteQuery) I get an error. It seems that the request XML is not created properly, I just see one line in the XML file. I then looked at the online docs and tried to emulate the code there:
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
cquery.CreateTime = DateTime.Now.Date.AddDays(-20);
cquery.SpecifyOperatorOption(Intuit.Ipp.Data.Qbo.FilterProperty.CreateTime,
Intuit.Ipp.Data.Qbo.FilterOperatorType.AFTER);
cquery.CreateTime = DateTime.Now.Date;
cquery.SpecifyOperatorOption(Intuit.Ipp.Data.Qbo.FilterProperty.CreateTime,
Intuit.Ipp.Data.Qbo.FilterOperatorType.BEFORE);
// Specify a Request validator
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
IEnumerable<Intuit.Ipp.Data.Qbo.Account> qboAccounts = cquery.ExecuteQuery<Intuit.Ipp.Data.Qbo.Account>(context);
unfortunately, VS 2010 insists that AccountQuery doesn't contain a definition for SpecifyOperatorOption and there is no extension method by that name. So I'm stuck.
Any ideas how to resolve this would be appreciated.
I can't find how my connectionString syntax is wrong. Can anyone suggest a way to figure this out? I am having a difficulty using EF with my connection string. I am new to EF.
I am using Sybase Anywhere 12 database.
I'm using the Table-First ObjectContext with EDMX in a separate class library refenced by a web application.
I'm using a Ninject Module in my class library to bind my repositories.
I'm using a ODBC DataStore called "Test"
Other information EF 4.3.1.0, .NET 4, VS2010
My main web application web.config has the EF connection string copied to it as:
<connectionStrings>
<add name="Entities"connectionString="metadata=res://*/MyEntities.csdl|res://*/MyEntities.ssdl|res://*/MyEntities.msl;provider=iAnywhere.Data.SQLAnywhere;provider connection string="UserID=aUser;Password=aPassword;DataSourceName=Test"" providerName="iAnywhere.Data.SQLAnywhere"/>
</connectionStrings>
When I initialize my Entity/ObjectContext in my Repository (see using statement below) it returns an error: "The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid."
using (var context = new Entities())
{
return {Linq to Entity here}
}
I turned on CLR exceptions on the debugger and found the code throws the error in the .NET Framework here:
EntityConnection.cs
effectiveConnectionOptions = new DbConnectionOptions(setting.ConnectionString, EntityConnectionStringBuilder.Synonyms, false);
edmx designer generated:
/// <summary>
/// Initializes a new Entities object using the connection string found in the 'Entities' section of the application configuration file.
/// </summary>
public Entities() : base("name=Entities", "Entities")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
I can see my connection string there, so it is having a difficult time parsing the connectionString. I have tried many different permutations of syntax and haven't found anything it accepts including:
Explicitly naming the assembly for entity files instead of a wildcard(e.g. metadata=res://MyDomain/MyEntities.csdl...)
Using Sybase friendly ODBC attributes such as UID instead of UserID, PWD instead of Password, and DBN instead of DataSourceName.
Thanks.
I got everything working and the only reason I can think of is that I deleted my ASP .NET 4.0 temp files. Also, I must add I changed my process from using an integration test to test this piece to using a unit test. I did not do unit tests first, because our build server does not have a database on it.
Once I was able to prove that it was working there, I decided to delete my temp files. After that, everything started working properly. So, some sort of cache issue was occurring in my application. I used the same connectionString that I mentioned above.
Actually, I used the domain name of the Metadata "metadata=res://MyDomain/MyEntitities.csdl" rather than */MyEntities.csdl. I don't plan on changing the domain any time soon. In fact, that is just what may have caused some of the issue, because I had changed the location, name, and namespace of MyEntities.Domain where the EF was.
It appears the MSDN docs are broken concerning creating an Event Log completely along with a definitions file for messages. I am also lost on how to setup Categories (I have custom numbers in the 3000's for messages).
Can anyone point me to a link or show sample code on how to make this right?
You should start (if you haven't done so already) here:
EventLogInstaller Class (System.Diagnostics)
The sample provided there is the foundation for what you want to do. To sum it up, build a public class inheriting from System.Configuration.Install.Installer in an assembly (could be the same DLL where you have the rest of your application, a separate DLL, or an EXE file), decorate it with the RunInstaller attribute, and add your setup code in the constructor:
using System;
using System.Configuration.Install;
using System.Diagnostics;
using System.ComponentModel;
[RunInstaller(true)]
public class MyEventLogInstaller: Installer
{
private EventLogInstaller myEventLogInstaller;
public MyEventLogInstaller()
{
// Create an instance of an EventLogInstaller.
myEventLogInstaller = new EventLogInstaller();
// Set the source name of the event log.
myEventLogInstaller.Source = "NewLogSource";
// Set the event log that the source writes entries to.
myEventLogInstaller.Log = "MyNewLog";
// Add myEventLogInstaller to the Installer collection.
Installers.Add(myEventLogInstaller);
}
}
When you have your assembly compiled, you may use the InstallUtil tool available through the Visual Studio Command Prompt to run the installer code.
Regarding the message definition file (which includes category definitions), the MSDN documentation for EventLogInstaller.MessageResourceFile mentions that you should create an .mc file, compile it, and add it as a resource to your assembly. Digging around, I found an excellent post which should guide you to the end, here:
C# with .NET - Event Logging (Wayback Machine)
I've been trying to integrate the latest version of autofac (1.3.3.54), and I'm running into the following problem.
The recommended way of consuming parameters in the Register callback, per the Google code wiki for the project is as follows:
builder.Register((c, p) => new Foo(p.Get("arg1")));
However this won't compile with the mentioned version of the autofac code. I looked through the source and I see that p is an IEnumerable (ComponentActivatorWithParameters). Is the code out of date with respect to the documentation?
It appears that the code has changed and the documentation on the Wiki has not been updated. The "Get" method is now "Named" and the "Parameter" class is now "NamedParameter". See the following example:
var builder = new ContainerBuilder();
builder.Register((c, p) => new Person(p.Named<string>("name")));
using (var container = builder.Build())
{
var person = container.Resolve<Person>(new NamedParameter("name", "Fred"));
}
Hopefully someone can update the documentation soon.
I've attached freshly built documentation for AutoFac 1.3 to AutoFac issue #121. I hope they'll resume posting official 1.3 documentation at least until they retire the 1.3 branch and, with it, support for .NET 2.0.