The project ask to call 3 separate files in this project for the bankers algorithm one is called a driver
include "banker.c"
include "process.c"
Related
I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
Lets say you have a client and a server project where these have some packages in common.
Is it possible to produce two exec files (client, server) from a single Ada project?
Using Ada 2012 with Gnat.
Yes. You can see an example of how to do it in the project files in my LEGO Tools repository. The critical part is to list the relevant compilation units in a "Main" clause in the project file like this:
for Main use ("build_mpd_file",
"fractal_landscape",
"outline_boundaries",
"pgm_to_ldraw",
"split_ldraw_file");
Yes.
There's nothing special about a subprogram that is to be the main portion of the executable. (There are some restrictions though; IIRC it has to be a paramaterless subprogram, and if a function has to return Integer.)
For GNAT, all that's needed is for you to specify which compilation-units are main files.
I'm using Jetty 8 to run some servlets. I have two (or more) applications that share source code, and I want to run them on the same port (i.e., 8080). I have placed two different WAR files into Jetty, one.war and two.war, so that I access them at, for example,
http://localhost:8080/one
http://localhost:8080/two
Both WARS contain an identical common JAR file (common utils). Does each WAR application get its own JVM? Really, I just want to be sure that the common JAR classes are entirely separate, since some of the classes are static and I need the two applications to obviously not share access to the same static class.
This seems obvious, and I seemed to confirm that it is the case that the common classes are loaded separately for each WAR with a simple test scenario (two identical WARs hosted in the same Jetty instance, but at different paths...see above). But I lack written documentation or confirmation that this is the case.
Each WAR file will have its own class loader see http://docs.codehaus.org/display/JETTY/Classloading. So you can safely use static classes.
An application I am working on is encapsulated inside an ear file, which contains a jar (containing EJB files) and a war (having, apart from its normal contents, package hierarchy of action classes, directly inside it). The context-root is specified in both WEB-INF/jboss-web.xml as well as in META-INF/application, and, well... is different in both.
The interesting part is that if I deploy that ear file in JBoss 4.2, I am able to access the application by the context-root given in application.xml, whereas when I deploy it in JBoss-6.1, I can access my application only with the context-root provided in jboss-web.xml. Why is this happening ?
Could there be a rationale for specifying two different context-roots in the 2 xml files ?
I have a native C++ DLL which is used as a plug-in in another application. This DLL has an embedded manifest and depends on a private assembly located in a folder external to the application. The application fails to load my plug-in DLL because my DLL depends on a private assembly which is never found (it is not located in the application directory, nor in the winsxs folder but in my plug-in directory whose location is not controlled by the application). The question is: how is it possible to make the system find my private assembly which is located in my own specific directory ? As an analogy, I would need an equivalent of setDllDirectory() but for assemblies. Or another way so that the system find my private assembly.
Constraints:
Because my DLL is a plug-in, I cannot install anything in the directory and sub-directories of the application. I also cannot modify the behavior of the application.
I would like to avoid sharing the assembly in winsxs.
I also have to use an assembly and not a simple DLL (that I could load with LoadLibrary) to avoid version conflicts.
Thanks.
you need to have a global location where you could give a list of directories that form your (from java-terminology) class-path. Once you have this list just traverse the directories looking for dll's.
I have used the Registry in windows for this. An environment variable or the /etc folder under linux would also do.
This is how linkers do it, and this is one way that the .NET GAC does (it specifies a list of directories in a registry key).
-- edit 1 --
Your problem seems quite a uncomfortable mix, it's like trying to eat with a straight jacket on :P. Why don't you drop the assembly requirement and have a function in a native DLL that returns a version identifier (name-version), and then have some application logic to determine if it may use the DLL.
For example file-name (fn) = monkey-1-1 and a function call returns a struct:
struct version-id
{
const char * name;
int major_number;
int minor_number;
};
Then fn monkey-1-2 would not conflict on file-name or internal conversioning. and your programming conventions or application logic would make sure no adverse collisions occur.