A while ago, I developed a WPF control and integrated into a third-party solution.
Just my luck, turns out the supplier also now use nlog (v2), which they have registered in the GAC. They don't currently use an nlog.config file, although they could do at some point.
I have used nlog v4, which isn't registered in the GAC but resides in the project's output folder instead. I do use an nlog.config file.
Two issues I would appreciate your advice with:
How would I isolate our nlog config file, can I rename it?
Would it be considered good practice to register my nlog.dll (v4) in the GAC also?
Your second question:
Would it be considered good practice to register my nlog.dll (v4) in the GAC also?
I would not recommend to use the GAC if it's not required. It makes upgrading more complicated and it's less transparent. NLog 4 is fully semver compliant, so it's easy to upgrade when keeping your nlog.dll in your local bin.
Related
This is possibly the dumbest question ever, but I've downloaded the jsPDF library from here: jsPDF. It's not offered through the NuGet packages, so how do I then use it in my .NET MVC project solution? Do I need to move the downloaded folder to the "Packages" folder in my project's directory? Do something else?
Obviously, I'm a total newbie to this, so please keep your answers uncomplicated if possible. Thanks!
A Nuget package is literally just a zip file of a compiled project. If it's C# code, it's a collection of DLLs, but depending on the project, it could have static resources like CSS, JS, etc. It could also have views or other resources. The long and short, is that all of this is just pretty much dumped into your project when you include a Nuget package, much as if you had simply added it yourself.
The slight exception is with DLLs, which are placed in packages simply to keep them organized, and then simply referenced by the project they were added to. Therefore, in order to add something not available as a Nuget, you simply just add all the stuff to your project. If there's JS/CSS and such, then just drop that somewhere in your project. If there's DLLs, create some place to house those on your filesystem, and then add a reference to them in your project. I would not recommend sticking them in the packages directory, because that's managed by Nuget, and it could clobber your DLLs if you put them there.
I have a largish application that currently uses log4cxx as its logging system. However, these appears to be a dead project, and I cannot get it to work with Visual Studio 2013. As such, I am looking to move to log4net
Our project is a mixed C+/C# project, using .net 3.5, and the logging is pretty simple
What is the best way to handle this migration. Any particular problems that people would expect to see, any required changes to config files, etc.
Also, is there a simple tutorial on how to use log4net. Unless I'm misreading it, it appears to be a case of reading the source examples until you figure it out.
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.
I download the latest copy of castle windsor. there are 2 folders, one is net40, another one is net40-client. which one I should use for my asp.net mvc3 application. I am using vs2010.
the tutorial I read from the castle windsor wiki web site tells me to use dll files in "net40" .
if I use NeGet to install the package. I notice It only has net40-client folder.
can some one please explain to me the difference between those 2 folders and which one I should use.
I think that net40 and net40-client are basically the same except the later does not depend on System.Web and, therefore does not have the per web request lifestyle.
I found this post that confirms that (kind of - it would be great if there were a definitive page somewhere that outlines the differences but I could not find one): http://www.mail-archive.com/castle-project-users#googlegroups.com/msg09398.html
Given you are in asp .net anyway I would suggest you went with the net40 version (as you will already be building against that profile).
We have a class library where we keep a lot of the stuff that we often use when doing sharepoint development. How would you go around deploying this? Right now our best bet is to have it in a separate solution, and deploy that so that the assembly is deployed to GAC. That way we ensure that the assembly is deployed to all application tiers and is available.
Is there a better approach than this?
GAC, of course, is the easiest way to deploy an assembly; however, what if you don't want to share this assembly across an entire server. Or what if the license doesn't permit that.
So, there are two ways to deploy an assembly:
GAC (you already know about it)
BIN folder. To deploy your assembly to the bin folder of your site (e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\80) you'll need to create a custom Security Policy file and change a security level in the web.config. This is not easy at all and can be quite frustrating but may be well worth it.
More information: http://msdn.microsoft.com/en-us/library/cc768621.aspx
The GAC is usually your best choice. Like ensuring you deploy to all applications, it's also easier in terms of security.
If I remember correctly, putting it in the GAC is the recommended course of action.
Also, remember that you have to add to the SafeControls list in the web.config.
http://grounding.co.za/blogs/brett/archive/2008/05/23/sharepoint-register-an-assembly-as-a-safe-control-in-the-web-config-file.aspx
I've decided to deploy it to GAC since the assembly doesn't pose a security risk since it will not be used from Web Parts.
I've researched a bit and deploying to gac is the recommended way to do it. You could argue that everything but Web Parts should be deployed to GAC. Since Web Parts pose a potentially security risk it can be a good idea to make your own CAS and deploy it to sharepoint bin.
Cheers.
Note that if you do decide to deploy to the BIN folder, you can deploy custom security policy settings such as new Permission Sets through your solution manifest file.