I inherited a small Microsoft Enterprise Library project that supposedly worked a couple of months ago. From what I can tell, it has code that was lifted directly from the Enterprise Library source (?!) instead of linking the built DLLs.
Sigh.
So, there are classes that don't compile in the Microsoft.Practices.ENterpriseLibrary.* namespaces. There's a reference to a cryptic LOGNS namespace which has a static LogHelper class with a bunch of Log* methods.
I can't figure anything out about this class, other than that it's missing (and trivial to stub out), but I'm concerned that I may be missing some references (in my GAC?) or something.
This is one trivial error out of several; I have a feeling this code did work (since it's ten projects in a solution), and only that I'm missing something locally.
But what?
There's no such namespace or class in Enterprise Library. Sounds like you didn't get all the source code.
Well, no current versions - any idea what version of Entlib you're dealing with?
Related
I use VS 2008 (it suits me, later versions offer me no benefits) and I am cleaning up my various libraries but running into some problems. I have always linked directly to source files rather than the dll produced by class libraries and thought I would switch to doing things "properly" by linking to the dll but it is causing me some problems.
I have several libraries but the current issue is caused by:
JGLibrary - just requires the Net Framework (I standardise on 3.5).
JGContacts - basis of my address book app, uses JGLibrary.
I am reworking my address book which uses both JGLibrary and JGContacts and am getting the following error message:
The type 'JGLibrary.JLibrary' exists in both 'd:\Data\Visual Studio 2008\Projects_Common\JGContacts\JGContacts\bin\Debug\JGContacts.dll' and 'd:\Data\Visual Studio 2008\Projects_Common\JGLibrary\JGLibrary\bin\Debug\JGLibrary.dll'
It is, presumably, because JGLibrary is used by both JGContacts and my address book - that's what a library is for.
Using the address book example should I just use the JContacts dll and rely on the fact that I can access my JGLibrary functions through it (which makes me slightly uncomfortable) or is there another way to manage this? I don't have this problem linking directly to the library files which makes me wonder if I should just go back to that but it does mean linking to a dozen or so individual files rather than just one dll.
I would appreciate guidance/thoughts.
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
What I mean by the title is, whether there's a free framework/tool that allows me to write .scala files and have them reloaded & compiled automatically by the (web) server without the need to compile, package and deploy.
Probably javarebel can be used here, but it is not free.
JRebel, which is the new name for JavaRebel, has a free license for Scala use.
Other alternatives include using Maven's scala:cc target, which keeps compiling on the background, triggered by changes, and, in particular, the Play framework is almost perfect in this regard.
Scala has an interpreter (scala.tools.nsc.Interpreter.) that can be embedded. The infrastructure to load changed files should not be to hard to implement. The interesting question is how do you handle instances of older class versions? The easiest approach is to throw away the instances and the classloader.
I do vaguely remember that JRebel is free for scala development. Not sure if this was only for open-source scala projects.