I've downloaded some code off the net which includes the UtilElementType::FeatureKey enumeration. This does not exist in Dynamics AX 2009.
What was its purpose?
More importantly, is there an equivalent I need to include in the code instead?
The UtilElementType::FeatureKey was used in AX 3.0 and prior, but removed in 4.0 and later. It was a mix of UtilElementType::SecurityKey and UtilElementType::ConfigurationKey.
You may substitute any or one of these.
Related
I've recently had to look for a C# porting of the Protocol Buffers library originally developped by Google. And guess what, I found two projects owned both by two very well known persons here: protobuf-csharp-port, written by Jon Skeet and protobuf-net, written by Marc Gravell. My question is simple: which one do I have to choose ?
I quite like Marc's solution as it seems to me closer to C# philisophy (for instance, you can just add attributes to the properties of existing class) and it looks like it can support .NET built-in types such as System.Guid.
I am sure both of them are really great projects but what's your oppinion?
I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.
Some points re protobuf-net that are specific to this implementation:
works with existing types (not just generated types from .proto)
works under things like WCF and memcached
can be used to implement ISerializable for existing types
supports inheritance* and serialization callback methods
supports common patterns such as ShouldSerialize[name]
works with existing decorated types (XmlType/XmlElement or DataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)
in v2, works for POCO types without any attributes
in v2, works in .NET 1.1 (not sure this is a huge selling feature) and most other frameworks (including monotouch - yay!)
possibly (not yet implemented) v2 might support full-graph* serialization (not just tree serialization)
(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)
Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)
Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.
According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.
I just switched from protobuf-csharp-port to protobuf-net because:
protobuf-net is more ".net like", i.e. descriptors to serialise members instead of code generation.
If you want to compile protobuf-csharp-port .proto files you have to do a 2 step process, i.e. compile with protoc to .protobin and then compile that with protoGen. protobuf-net does this in one step.
In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.
For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.
Can I setup my own naming conventions in VS code analysis?
For example:
m_VarName;
VarName;
varName;
This will be possible in Visual Studio 15.
We've also added/updated style analyzers to help you customize and
enforce coding conventions on your team, including:
https://www.visualstudio.com/en-us/news/releasenotes/vs15-relnotes#debuggingdiag
Should be able to. Though I don't see why you don't just type them as you go, no needed to really set up a name convention in VS :)
I am attempting to use Hammock as a library to enable easy access to a REST API.
When I add the package using nuget in Visual Studio 2010, it adds 2 references:
Hammock
Hammock.ClientProfile
However, when I attempt to use the hammock classes and methods, it tells me there are duplicate implementations of certain classes. Further, using full namespace scoping does not seem to help.
Is it possible that one should be using only Hammock -or- Hammock.ClientProfile - but never both at the same time?
If so, why?
I have contacted the the creator, and he stated that there is no difference between the libraries - he was at one time planning to implement a server-side library, but never followed through on it.
My personally, I am using Hammock (and not using Hammock.ClientProfile).
In VS2010 and .NET 4.0, I see the shortcuts in intellisense for adding contracts to my code (Eg cr, crr) but when I tab to add these in, the code (Such as Contract.Requires) does not have the valid assembly so there is no intellisense (The type can't be found basically).
How exactly do I get up and running with code contracts?
EDIT: All the methods exist in System.Diagnostics.Contracts, but I thought that I would be using attributes throughout? Also, there are so many different .dlls for the contracts available!
Thanks
The assembly is just mscorlib - and Contract is in the System.Diagnostics.Contracts namespace.
<plug>
For some more information about Code Contracts, you could buy the second edition of C# in Depth and read chapter 15. (That chapter was available free, but isn't now I'm afraid.)
</plug>
Or of course you could read the docs too, as they're pretty good :)
If you find you're missing the System.Diagnostics.Contracts namespace, it's worth checking that you really are targeting .NET 4 - if you create a .NET 3.5 project in VS2010, that won't have Code Contracts available (without adding an explicit assembly reference, anyway).
I'm working with Linq expression trees (from the db4o/Mainsoft/Mono port) on the Compact Framework. Since System.Reflection.Emit doesn't exist, I can't compile my LambdaExpressions into delegates, which I want to do for performance reasons.
I thought maybe I could transform my expression tree into IL and basically provide the missing Emit functionality that way, but then I realized that I'd have to either run a WinCE-based ILASM on it or write my own PE headers and assmebly metadata.
I'd much rather have ILASM available. Is it?
Apparently, I can compile Mono.Cecil for use under the Compact Framework, which will allow me to emit and load assemblies.
If you want use a Lambda-Expressions on CF you don't need ILASM or System.Reflection.Emit. The C# compiler for CF supports Lamba-Expressions but the CF base libraries does not have the Expressions classes. If you add reference to assembly with correct named (and correct implemented) classes for expressions, you enable Lambda-Expressions.
Thanks for god, there are this assembly already implemented ( http://evain.net/blog/articles/2008/09/22/linq-expression-trees-on-the-compact-framework ) - I use it with Db4O data access and for SqlCE wit LINQ IQueryableToolkit, and it works well.