What is the use of this file in a RAD : org.eclipse.wst.common.component. The contents are like this:
<?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="WebProj">
<wb-resource deploy-path="/" source-path="/src/java"/>
<wb-resource deploy-path="/" source-path="/test"/>
<wb-resource deploy-path="/" source-path="/test/conf"/>
<wb-resource deploy-path="/" source-path="/src/conf"/>
<property name="java-output-path" value="src/java"/>
</wb-module>
</project-modules>
In RAD,the builds are integrated with Eclipse and so there are all these oddball files that you may not recognize if you are not used to dealing with RAD/Websphere. It looks like this one configures the context root and what source directories to build out for the web app. In RAD, you're not supposed to edit these files directly--there is an (often obscure) UI for everything. There is also an equally obscure way to script everything in each UI, too.
Related
I just upgraded my .net core 2.0 project to 2.2. To my knowledge, I didn't change any other settings, but now when I publish to my file system, it publishes a ton of folders and dlls that it didn't before.
Do I need to publish them? If not, can I suppress their output?
Here is my publish profile settings:
Here is what the output directory looked like before the upgrade:
Now, here is just a snippet of what the output directory looks like:
Introduction: This issue seems to result from .net core 2.0.
From the picture you shared above. I know you choose Framework-Dependent Mode.
In this mode, generated files should be like what you have in picture1. And if your choose self-contained mode, generated files should be like what you have in picture2.
But in .net core2.0, there seems to be some different. When we publishing projects in .net core2.0, or just upgraded from 2.0 like yours. We must set self-contained property to false explicitly so that the Framework-Dependent mode can work normally.
Do I need to publish them?
No, you don’t need to publish generated files from self-contained mode as you choose framework-dependent mode.
If not, can I suppress their output?
Here is one workaround:
Looks like you use VS IDE to publish it, when publishing make sure choose 'create profile'. So we will have a PublishProfile, we can find it below Properties in Solution Window. Open the FolderProfile.pubxml and add the <PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest> in the PropertyGroup. Also, we can set the <DeleteExistingFiles>false</DeleteExistingFiles> to true.
After that, publish the project again the issue can be resolved.
The final format of PublishProfiles looks like below:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<publishUrl>bin\Release\netcoreapp2.2\publish\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
</Project>
In addition: You can find more info from this issue. Thanks to natemcmaster. His advice do work at my side.
I'm facing a really strange problem.
I have an application built in C++ Builder 2010. This application reads and writes a bit to the registry. Since it's a 32-bit application these keys end up in the wow6432Node. Every now and then it has appeared as though it has trouble reading the values from the registry. But only when build on the build server (using TeamCity) and never on the dev machines. Often a new commit and a rebuild would make the issue go away so it was hard to diagnose.
After some testing I noticed that I was able to reproduce it on the dev machine to. But only when building from the command line by calling msbuild manually. If the exact same project is built within the IDE there are no issues. But the exe produced when building from the command line, for some reason, can't read values from the registry.
There are no errors or warnings during builds. No files it can't find due to invalid paths or anything like that. Since msbuild is, as far as I can tell, used by the IDE when building to this has me scratching my head. I have tried to manually use different versions of msbuild etc, but nothing works.
So basically, on the same machine, my produced exe behaves differently depending on if I manually started the build from the command line or if the IDE started the build.
What on earth could this be?
After spending a lot of time trying to force the application to use specific registry views etc I was encouraged to look into the UAC manifest settings. I found that the application did in fact have a manifest file, named correctly and in the correct spot. It was also included in the .cbproj file and compiled by the resource compiler.
But, something got me thinking that perhaps it's not being used correctly. After some digging it seems like if runtime themes is enabled for the project that will create a "default" application manifest that will be used.
Disabling runtime themes will allow the compiler to actually use your custom application maniftest file (not exactly well documented, but I have found that to be the case with a lot of Embarcaderos things). By doing this I was able to set the required execution level for the application and things started to work just fine.
You can still manually enable the support for runtime themes in the maniftest file you create. You forms might look a bit strange in the ide since that will think that runtime themes are disabled.
To manually add runtime theme support you add the dependency to your custom application maniftest.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"
/>
</dependentAssembly>
</dependency>
...
</assembly>
Save it as Foo.exe.manifest, where Foo.exe is your application name.
You then create a .rc file for your application. For instance FooManifest.rc
#define MANIFEST_RESOURCE_ID 1
#define RT_MANIFEST 24
MANIFEST_RESOURCE_ID RT_MANIFEST "Foo.exe.manifest"
Now you will be able to build your application using your own custom application manifest and still maintain support for runtime themes.
I have a NetBeans mavenized project Contaning:
web project (war)
ejb project (jar)
parent project
maven project
After every change I must clean an build the maven project and Run the Parent project
How canI configure my projects to auto deploy on save ?
the configuration file(nb-configuration.xml) is as follows :
<?xml version="1.0" encoding="UTF-8"?>
<project-shared-configuration>
<!--
This file contains additional configuration written by modules in the NetBeans IDE.
The configuration is intended to be shared among all the users of project and
therefore it is assumed to be part of version control checkout.
Without this configuration present, some functionality in the IDE may be limited or fail altogether.
-->
<properties xmlns="http://www.netbeans.org/ns/maven-properties-data/1">
<!--
Properties that influence various parts of the IDE, especially code formatting and the like.
You can copy and paste the single properties, into the pom.xml file and the IDE will pick them up.
That way multiple projects can share the same settings (useful for formatting rules for example).
Any value defined here will override the pom.xml file value but is only applicable to the current project.
-->
<netbeans.compile.on.save>all</netbeans.compile.on.save>
</properties>
</project-shared-configuration>
right click on your project then select 'properties'. Now, click on 'run' option here select deploy on save. Hope it helps.
Sometimes, restarting NetBeans and server helps to solve autosave problem. It's truly strange, but in my case it helped.
I have a Spring application that is being deployed to JBoss 4.2. I can manually edit the generated WAR file and alter the jboss-web.xml file to set the context-root value and that works perfectly well. I would like to be able to do the samething via netbeans (6.9.1), but I have been unable to locate where to make the adjustment. I've tried tweaking the project's properties and setting the Context Path value. When I Run the application that value is reset to the Project's name. I've located the jboss-web.xml file in the project and changed it there, also reset upon run. So it appears that Netbeans is deciding that the value need to be set but I can't locate where. If it's of any use, the project also uses Maven2, but all the controls I can find for impacting context-root are geared towards EAR files instead of WAR.
Has anyone been able to do this or am I just in a world of making the change post build?
I had a similar problem once where netbeans was sometimes removing the context-root element from the glassfish-web.xml configuration. I have not been able to track it down exactly but you could try to remove the file nb-configuration.xml in the project root folder and see if that helps.
My code is a plugin for a specific Application, written in C++ using Visual Studio 8. It uses two DLL from an external provider. Unfortunately, my plugin fails to start because the DLLs are not found (I put them in the same directory as the plugin itself).
When I manually move or copy the DLLs to the host application directory, then the plugin loads fine. This moving was deemed unacceptably cumbersome for the end user, and I am looking for a way for my plugin to load its DLLs transparently. What can I do?
Relevant details:
the host Application plugins are located in a directory mandated by the host application. That directory is not in the DLL search path and I don't control it.
The plugin is itself packaged as a subdirectory of the plugin directory, holding the plugin code itself, but also any resource associated with the plugin (eg images, configuration files…). I control what's inside that subdirectory, called a "bundle", but not where it's located.
the common plugin installation idiom for that App is for the end user to copy the plugin bundle to the plugin directory.
This plugin is a port from the Macintosh version of the plugin. On the Mac there is no issue because each binary contains its own dynamic library search path, which I set as I needed to for my plugin binary. To set that on the Mac simply involves a project setting in the Xcode IDE. This is why I would hope for something similar in Visual Studio, but I could not find anything relevant. Moreover, Visual Studio's help was anything but, and neither was Google.
A possible workaround would be for my code to explicitly tell Windows where to find the DLL, but I don't know how, and in any case, since my code is not even started, it hasn't got the opportunity to do so.
As a Mac developer, I realize that I may be asking for something very elementary. If such is the case, I apologize, but I have run out of hair to pull out.
You are not asking for something very elementary. Windows simply does not support what you want.
You have some options to work around this issue:
Create two DLLs. Your plugin implementation dll, that statically links against whatever other dlls you need. And a simple "facade" dll that is loaded by the hosting app. The facade dll gets to call SetDllDirectory then LoadLibrary to load your implementation dll with the required search path, and then, for each plugin exported function, it implements a stub function that uses GetProcAddress to just pass the call straight to your implementation dll.
If the plugin interface is complicated, but the dll interface you are using is not, then:
Give up and just use LoadLibrary (with an explicit path) and GetProcAddress to access the functionality in your satellite dll(s). Pain.
The final option is the least documented and most badly understood by windows programmers. Basically we use the windows version of a technology built to support .NET: Side by Side assemblies. Don't be frightened. A "Side by Side assembly" is very simply a regular old dll, but with a accompanying .manifest file that provides some extra information about it.
The reason we want to do this is the search order for dlls that are linked in via the SxS technology is different to the regular dll search order :- Namely - after searching c:\windows\WinSxS, windows will search the same folder as the dll that references the dll, NOT the folder of the exe.
Start by taking an inventory of all the satellite dlls your plugin dll needs to link to, and create an "assembly" from them. Which means: create a .manifest file with a bunch of file= nodes. You need to give the assembly a name. Lets call it "MyAssembly".
Create the file "MyAssembly.manifest" in your dll's folder, with contents similar to the following: (listing each of the dlls you need to include)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="MyAssembly" processorArchitecture="*" type="win32" version="1.0.0.1"/>
<file name="firstrequireddll.dll"/>
<file name="2ndrequireddll.dll"/>
</assembly>
Now, thats your assembly manifest. We are half done.
The next half is to actually get your dll to use the assembly, and to do that you need to add a manifest resource to your Dll file. That manifest ultimately needs to contain the following content :-
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="MyAssembly" version="1.0.0.1" processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>
Apparently application manifests (which is a confusing name when embedded in a dll), are also allowed to use a <file> node, so it might be possible to skip creating an assembly, and just go with
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<file name="firstrequireddll.dll"/>
<file name="2ndrequireddll.dll"/>
</assembly>
as the dll's manifest. I havn't toyed with that iteration yet, so Im not sure how that alters the normal dll search path (if at all).
Without knowing your development environment, its hard to know how to advise you how to add a manifest to a dll. If you are editing a .rc file and entering the manifest by hand, know that in Dlls the resource id to use is 2, not 1, which it typically used in exe examples.
If you are using DevStudio 2005 or higher, there is a handy #pragma directive that will make everything magically have the correct id's and be in the correct places.
If the project settings are on their defaults, VS2005 and up will automatically generate, and embed a manifest as appropriate. this #pragma will add additional assembly dependencies
to the generated manifest :-
#if _MSC_VER >= 1400 // VS2005 added this directive
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Company.Product.Subsystem' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"language='*'\"")
#endif
Delay loaded DLLs are your friend in this situation. I faced the exact same problem a while back and it's actually rather simple. You specify to the linker (/DELAYLOAD flag) which modules are delay-loaded and basically they modules are not listed as explicit imports in the PE header so the loader won't complain when it cannot find the said modules and all the calls to functions from those modules are wrapped in a stub which ensures the module is loaded & the function is found.
So, let's say you wished to delay load the XmlLite library. First you'd specify /DELAYLOAD:XmlLite.dll in the linker flags. Then in your module's initilization function (preferably DllMain) you'd unpack the XmlLite DLL into a temporary folder and then call LoadLibrary on it. From there on it, each call to any function exported by XmlLite.dll would be resolved automatically.
Use GetModuleFileName() to find the path where your dll is located.
Then use SetDllDirectory() to add that path to the dll search path.
Assuming native code and that you can use explicit run-time dynamic link (rather than any form of implicit link), use GetModuleHandle and GetModuleFileName to find out where your dll is running from.
HMODULE hModule = GetModuleHandleW(L"RunningDll.dll");
WCHAR path[MAX_PATH];
GetModuleFileNameW(hModule, path, MAX_PATH);
Then replace the base name of the dll with the name of the plugin.dll you want to load.
CString plugin(path);
int pos = plugin.Find(L"RunningDll.dll");
plugin = plugin.Left(pos);
plugin += L"pluginName.dll";
Call LoadLibrary on the generated string.