Looking to format (automated, in application) some html / nvelocity templates. Tidy seems to be the answer for this, however all the .Net ports seem to be problematic and not very well maintained. Most rely on unmanaged code under the covers and that starts imposing other restrictions on the project.
For example, to use the code associated with http://www.codeproject.com/KB/mcpp/eftidynet.aspx, the projects now has to be a x86 build.
Is there a new preferred solution for doing this? Or is there a completely managed port of TidyHtml that understands nvelocity or allows custom token definition?
Let's list them:
EfTidy
ZetaHtmlTidy (mixed-mode, so it needs different assemblies for x86/x64)
tidyfornet (managed assembly but depends on external HTMLTidy native dll)
TidyATL (ATL wrapper, old, unmaintained, I think it's also mixed-mode and it even requires COM registration?)
TidyNet (fully-managed DLL, no external dependencies)
Even though it's old and unmaintained, I'm using TidyNet because it's fully managed. Does the job just fine.
BTW: Tidy and NVelocity are completely unrelated. I'd never process NVelocity templates with Tidy as it will probably break them... However you might want to run Tidy to the resulting html after processing the NVelocity template.
Related
I've searched far an wide for this specific problem, but I only find separate solutions for each problem individually. I basically want to know what the name of the environment variable should be. My assumption is that the name of the variable should be the name of the component and that it should be User variable and not System variable, for example:
name -> "mydll.dll"
path -> "c:\myCustomPath\mydll.dll"
The reason why I want to do this is because of two reasons. First, I often run my custom made tools either directly from the source code in a VM (which is sort of a pain), or I compile it and run it in W10. However, I just cannot do that with more complex apps that have dependencies because then I would have to register tons of DLLs onto the system root, and I know that I would lose track of it easily. The second reason is because I read this reply the guy says it's not recommended to use the system root for private libraries and he also suggests using an environment variable which sounded like a good solution to my problem.
The reason why I have not tested this myself through trial and error is because I'm afraid of leaving my only computer unusable if I put something wrong in the variable. Also all the libraries and exe files that I'm using are written and compiled in VB6, so I have no easy way around it since I already tried merging the multiple projects into one on a rather small project. I ended up rewriting almost the whole thing because VB6 doesn't like public types enums, etc in private Object Classes.
Finally, I am not sure if my question should be here since it doesn't involve programming, but I just felt it would be better understood here.
If I understand your question correctly, you are asking where you can place COM DLLs so that you can register them on your computer.
The answer is - fundamentally - that it does not matter where they are located because registration has a "global" effect. (Simplifying a little).
Now of course there are standards or conventions for where system-wide registered DLLs should go - e.g., Windows\SysWOW64 folder. But the point is that if you register the wrong thing, or leave out dependencies, or remove a registered DLL without unregistering it - etc. etc. - you will cause problems.
I am not aware of any environment variable that has anything to do with this basic function of COM DLLs. (I may be ignorant of something).
If you are actually using an application manifest (as maybe implied in the question) then you don't need to and should not register any DLL which is manifested.
My application has a plugin system that allows my users to write their own plugins that get loaded at runtime. Usually this is fine but in some cases two plugins use the same libraries that will cause a collision between those two.
Example:
Plugin A wants to use TouchJSON for working with JSON and thus the creator adds the TouchJSON code to the plugin source and it gets compiled and linked into the plugin binary. Later Plugin B also wants to use that same library and does exactly the same. Now when my app loads these two different plugins it detects this and spits out an warning like this:
Class CJSONScanner is implemented in
both [path_to_plugin_a] and
[path_to_plugin_b]. One of the two
will be used. Which one is undefined.
Since my app just loads plugins and makes sure they conform to a certain protocol I have no control over which plugins are loaded and if two or more use the same library.
As long as both plugins use the exact same version of the library this will probably work but as soon as the API changes in one plugin a bunch of problems will arise.
Is there anything I can do about this?
The bundle loading system provides no mean to pacifically resolve name conflicts. In fact, we're told to ensure ourselves that the problem doesn't happen, rather than what to do if it happens. (Obviously, in your case, that's not possible).
You could file a bug report with this issue.
If this is absolutely critical to your application, you may want to have bundles live in separate processes and use some kind of IPC, possibly NSDistantObject, to pass the data from your program to the plugin hosts. However, I'm fairly sure this is a bag of hurt, so if you don't have very clearly-defined interfaces that allow for distribution into different processes, it might be quite an undertaking.
In a single-process model, the only way to deal with this is to ensure that the shared code (more precisely, the shared Objective-C classes) is loaded once. There are two ways to do this:
Put the shared code in a framework.
Put the shared code in a loadable bundle, and load the bundle when the plug-in is loaded if the relevant classes aren’t already available (check using NSClassFromString()). The client code would also have to use NSClassFromString() rather than referring to classes directly.
Of course, if you aren’t in control of the plug-ins you can’t enforce either of these schemes. The best you can do is provide appropriate guidelines and possibly infrastructure; for instance, in the second case the loading could be handled by the application, perhaps by specifying a class to check for and the name of an embedded bundle to load if it isn’t available in the plug-in’s Info.plist.
I have 2 .net dll's which I expose to COM using REGASM. In order to simplify referencing within a COM client I would like to make these into one file.
I have tried converting both files to IDL and then copying the contents of the Library section of one into the other and then compiling back to .tlb with MIDL. This works fine for the TypeDefs within the second IDL however it seems to fail when it comes to the interfaces I copied in. OLE/COM viewer can see the interface definitions but when I try and use the TLB via COM it cant find the interfaces that I copied in.
I wanted to make sure before I spend too much time on this, that it is actually possible to meagre IDL's in this way.
Could you use ILMerge to first combine the .NET assemblies and then use REGASM on the resulting assembly?
ILMerge is a utility for merging
multiple .NET assemblies into a single
.NET assembly. It works on executables
and DLLs alike and comes with several
options for controlling the processing
and format of the output.
I don't see an obvious way this would fail. You said you merged the library sections but you didn't say you copy-pasted the interface declarations from the other .idl. That would be an obvious, but unlikely, explanation.
One failure mode is when the client app uses the type library to marshal interface pointers across apartment boundaries or out-of-process. That however requires registry keys in HKCR\Interfaces. .NET doesn't create them, you'd have to do that yourself. You'd know if you did, not much of an explanation either.
Ok so it turns out that the issues I was experiencing were not related to merging the idl's.
If you wish to merge to idl's you can do so by simply copying the content of a library section in one idl into another. Then run midl on the merged file to turn it into a tlb.
Apologies if this is a duplicate, but I've not managed to find this question being asked directly.
The general opinion here (that's me and him across from me) is that they shouldn't, the reason being that DLLs can be shared; therefore the idea of having application-specific information in a DLL is nonsense. If the information is not application-specific, then constants can be used.
A further question is, assuming that DLLs do not have their own config file, whether DLLs should use the configuration files of the executable that loaded the DLL, or instead be passed the relevant data as part of some kind of constructor. Our opinion here is the latter, as it makes it more testable, the downside being that it will sometimes be necessary to pass a significant amount of data to the dll.
Opinions?
There's no reason why you can't have the best of both worlds in terms of "simple to configure with config files" and "testable". Have a static method which can create instances from the configuration file, but also provide a constructor for more control and testability. The static method would just grab the settings and call the constructor.
I believe it's possible to create settings classes for DLLs just like any other project, and then you just need to put the actual text into the application's config file instead of one for the DLL. Basically ignore the app.config generated for the library project, except to use as a template for the application's central one.
Alternatively, use something like Spring.NET to manage this sort of thing :)
Usually, I guess you should pass relevant information to the functions you're calling or set relevant properties in objects you're creating that are defined within the DLL. I guess that's why .NET does not really support config files for DLLs (you can create them, but they'll not be used when running).
I have one scenario, where DLLs are reading a config file, but that is very special: The .NET DLL exports objects as COM objects for use by Microsoft Navision. It communicates with a factoring bank using an XML-RPC interface.
While the DLL is installed on every user's machine, the configuration for the interface is common to all users, so I have a configuration placed on a network drive that's mapped on every PC and the configuration (URL, credentials, etc.) is read from that common file.
Whether that's good practice is up to the reader, but in that scenario having a common config file just made sense...
Two of our apps are web applications with a Flex 3 front end and a SOAP-style WCF back end. To communicate with the back end, I generate web service client classes through Flex Builder 3. Everything's functional, but maintaining those generated classes has been quite annoying, and I'm looking for a better way to do things (without having to do a major rewrite, of course). Here's the problems:
I use Flex libraries to manage components shared among applications. Some of them are dependent on the generated classes, so I need the WSDL-generated classes in their own library. Flex Builder 3, however, only generates the classes for a Flex application, so I have to generate the files in the application's source tree, then manually move the files every time. This also introduces strange side-effects with the way that Eclipse manages source code (why can't it just monitor the FS like other IDEs do?).
We use data binding in the MXML to declaratively tie data to the UI. I like data binding. Unfortunately, the classes in the WSDL-generated code do not support binding. Therefore, I opted to create a program to alter the ActionScript classes, adding [Bindable] metadata to them. This has to be run every time we regenerate the code.
Flex has a very nasty bug, known about at least since March, which still hasn't been fixed: http://bugs.adobe.com/jira/browse/SDK-19811. I recently discovered this, because it was double-encoding some XML characters like < and & into < and &. Therefore, I also had to add a workaround for that to the ActionScript manipulation program.
The WSDL-code generator in Flex Builder creates a String, Boolean, Int, and other classes which are built-in types! We're always having to delete these source files to prevent the Flex compiler from sometimes balking.
It seems unlikely to me that everyone is just putting up with these issues. There must be some alternative way of generating web service proxy classes for Flex that others are employing. Since I'm time-prohibited from making the communication layer RESTful and rewriting the front end in Silverlight, what do you suggest?
You can use one of several mechanisms to read the WSDL into a program and generate whatever flex code you need.
You can use one of the two ServiceDescription classes to read in a WSDL and examine its contents in terms of an object model;
You can use T4 Templates in Visual Studio with a bit of custom work to expose the WSDL to the template (possibly through the ServiceDescription class, as above)
You can use XSLT to transform the WSDL into the code you'd like
You can write some standalone program to read the WSDL (as XML or an object model) and just emit the text you want for your proxy code.
The bottom line is that, if you're having problems with the automation tools, then there are practical ways of creating your own.
Unfortunatly Flex 3 code generation from WSDL lacks from the Bindable tag, and it is a nightmare to handle that problem manually... especially if you have a complex scenario with lots of Types.
You could just add the tag manually and remove the "generated.webservices" from all variable declarations in order to make the code compile... and then you have another problem:
What if i have to generate de code again? Either i do everything again... or i will have a bunch of runtime only detected bugs...
I used ANT to a small trick:
Add Bindable to all classes;
Remove the full namespace from all variable declarations;
<target name="updateGeneratedCode" >
<replace dir="PATH TO YOUR GENERATED CODE">
<include name="**/*.as"/>
<replacetoken>public class</replacetoken>
<replacevalue><![CDATA[[Bindable]public class]]></replacevalue>
</replace>
<replace dir="PATH TO YOUR GENERATED CODE" value=":">
<include name="**/*.as"/>
<replacetoken>:generated.webservices.</replacetoken>
</replace>
</target>
Note: the replace token ":generated.webservices." may be different in your case, so you may want to replace it by your generated namespace.
It is working for me so far.
Hope it helps someone!
Antonio Inacio