Does it apply to any aspect?
Is that it?
If I use a multicast attribute it will apply randomly to the first 10 matches only?
I'm not sure if I got this restriction right. Do you mind elaborating it a little?
Examples would be well welcome'd.
Starting from PostSharp 4.3, this limitation applies to any aspect. The build will fail if you apply aspects to more than 10 targets (with Multicast or not). So no randomness happens.
If PostSharp 4.3 detects that your project would have been built successfully with PostSharp 4.2 or prior, then the backward-compatibility mode is enabled and the project will be built by PostSharp 4.3 without error. Please refer to PostSharp 4.2 API documentation to check if an API used to be available in PostSharp Express.
Related
I am in the process of converting the deprecated methods & classes of WFFM from 8.0 rev.150429 (Update-3) to 8.1 rev. 151008 (Initial release). Sitecore provided a good documentation > release notes for the 'breaking changes' that would occur when converted to WFFM 8.1.
Link to release note:
https://dev.sitecore.net/Downloads/Web%20Forms%20For%20Marketers/Web%20Forms%20For%20Marketers%2081/Web%20Forms%20For%20Marketers%2081%20Initial%20Version/Release%20Notes
And that includes moving some classes from Sitecore.Form.Core.dll to Sitecore.WFFM.Abstractions.Actions.dll (okay I understand).
However, though I am not really sure, maybe I just couldn't locate the right page/site, but there were also some changes made in the Sitecore.Forms.MVC 8.0 to 8.1 which were not documented. To be specific, classes are as follows:
Sitecore.Forms.MVC.Models.FieldModel (removed in Sitecore.Forms.MVC 8.1)
Sitecore.Forms.MVC.Models.SectionModel (removed in Sitecore.Forms.MVC 8.1)
Maybe there were also other classes that were removed, as well. But I am only concerned about the above two (2) classes for the mean time.
So, I'd like to know if someone already ran into this scenario before when upgrading WFFM to 8.1 and how you were able to resolved the issue?
I have a hint that I just have to look for the NEW DLL that uses or implements the FieldModel and SectionModel, but again, I couldn't find it as of this writing.
Appreciate any help. Thanks.
There is no FieldModel and SectionModel anymore, but I assume you are looking for the FieldViewModel and SectionViewModel. They can be found still in Sitecore.Forms.Mvc in the Sitecore.Forms.Mvc.ViewModels namespace.
If you need more specific classes, you can check the Sitecore.Forms.Mvc.ViewModels.Fields as well - or open the Sitecore.Forms.Mvc dll with a decompiler (as I did).
I have a requirement to create a framework for a shared set of common utilities that we plan to use in multiple iOS projects in our organization. The utility classes are written in swift and the framework needs to support projects in iOS 7 and above. I'm using Xcode 6.1.1.
I tried creating both a 'Cocoa Touch Framework' and a 'Cocoa Touch Static Library' and can't seem to get it working for iOS 7 builds.
With 'Cocoa Touch Framework', I get a warning that 'Embedded dylibs/frameworks only run on iOS 8 or later' and though I can get it to run, it fails during the iTunesconnect step with an error that the project's deployment target must not be less than 8.0 (mine is 7.0).
I tried with 'Cocoa Touch Static Library' as well using the steps given in http://www.raywenderlich.com/65964/create-a-framework-for-ios, but it just does not build with swift files. When I remove all swift files and add Obj-C files, it works properly.
Any help is greatly appreciated. How do I create a framework for a swift project with iOS 7+ support?
Thanks
Unfortunately, you cannot. It's one of the more disappointing factors about Swift.
As shown in the documentation, you cannot make a static framework/library with swift and dynamic libraries are only supported in iOS 8+.
The only option I recommend is that you develop an Objective-C static framework for iOS 7 and then begin to use swift when you wish to drop iOS 7 support. It's not the most ideal situation, but because you are able to have mixed languages in a dynamic framework, it means you won't have to waste time rewriting code (unless, of course, you want to).
Apple not supporting pure Swift frameworks before iOS 8 is somewhat hurting Swift adoption rate.
I'm not advocating the following solution as best practice. Honestly, it's a very flawed hack. We have a large pure Swift framework that does most of the heavy lifting for things here at work. And, we needed that framework in a product that ran on iOS 7.1+.
Here is the hack - Directory hierarchy is important. In an ideal situation, the project and the framework are siblings in the directory tree. Create a group in the project. In Finder, shift/command select all of the source files from the framework, and drop them into the newly created group. Make sure not to copy the files. Your telling Xcode to simply add the files to the project file, creating relative path links to them.
The framework should now compile directly into your project. I can't emphasize enough how fragile this solution is. As files are added to your framework, they also have to be added/linked into any project that you've "link embedded" the framework.
This "solution" should only be used as a last resort. Having to repeat framework parity across multiple projects is dumb. If time goes by with the project staying static, and the framework evolves, dump the framework in the project, and re-add it. It takes less than a minute to dump/re-add the framework, and reduces the chance of error.
Apple, please help us, so we can maintain best practices. I'm embarrassed to share this solution, as it's just a horrible way to get around something Apple is not supporting.
I got the .Net Demon trial from RedGate and it seemed to be working great, but I just realized a PostSharp aspect I'm using is being ignored and I'm not sure why... wondering if it has to do with the fact that they both do stuff with the build system.
Is anyone else using them together successfuly? I'd like to buy .Net Demon, but not if my PostSharp stuff won't work, of course. Not sure if it's related or not yet though.
We (SharpCrafters) do not officially support .NET Demon. Since Demon is an incremental compiler and PostSharp does not support incremental compilation (it compiles the whole assembly every time), I doubt it could work and, if it worked, I doubt it would have any effect on performance. Since the build time is typically dominated by PostSharp, reducing the time of the C# compiler would not significantly reduce your complete build time.
.NET Demon compiles the whole assembly each time it compiles, including any post-build steps that are in the .csproj. I don't see why it shouldn't work. Look in the build output to see whether any logging normally produced by PostSharp is there.
I have used FxCop 1.36 and I recently upgarded to FxCop 10.0. Using the same set of rules and the same set of assemblies now I got less warnings.
Have they removed some rules from the FxCop 10.0? If so, why?
I know of only one rule (Performance.DoNotInitializeUnnecessarily) that appears to have been completely removed in 10.0. However, there are some other changes that may be affecting your violation counts:
The logic of several rules has been improved so that they will detect less false positives. For example, there are some security rules that detect issues that are only problems when running on .NET 1.x. If you target later framework versions, you should no longer see violations for these rules in FxCop 10.0.
The rules around security transparency have changed quite a bit. Some old rules have been removed, but they've been replaced by other rules that should detect similar problems. In addition, quite a few new transparency rules have been added. Depending on whether you've upgraded your code to .NET 4.0 and how you've set up your transparency/criticality, you may be picking up less transparency violations than you did before.
it's difficult to trac the different versions of fxcop. Is version 10 compatible with 3.6?
Can version 10 also profile .net 3.5 code?
In beta builds of Autofac 2.1 there was support for automatic resolution of Lazy<T> as described in Nicholas Blumhardt's Lazing Around with Autofac blog post.
The code still seems to be in the source on Google Code, but I can't find LazyDependencyModule in any of the .NET 4.0 binaries I've looked at. Has it moved somewhere else?
How do I use Autofac's automatic Lazy<T> resolution with the latest Autofac builds?
You don't need to register LazyDependencyModule yourself in the production Autofac 2 builds. It is a part of the default container, so just register T and Lazy<T> will be provided.
Make sure you're not accidentally using a .NET 3.5 binary, too :)
Nick