It looks like there are two SBT plugins for running ProGuard. Can anyone speak to their relative strengths and weaknesses? I haven't found a comparison online yet.
xsbt-proguard-plugin - https://github.com/adamw/xsbt-proguard-plugin - ~2 year old independent project; last touched on GitHub 6mo ago
sbt-proguard - https://github.com/sbt/sbt-proguard - ~5 mo old project; part of sbt official repo; last touched on GitHub 2 days ago
I'm assuming xsbt-proguard-plugin is generally more mature, but why would the SBT folks spin up their own?
I've tried both. They are similar in function, though each has minor quirks.
I couldn't get the "merge" function in sbt-proguard to work, probably due to a temp directory naming bug.
However, I ended up choosing sbt-proguard over the other one anyway, because xsbt-proguard-plugin does not provide the output in a way that can be accessed from sbt, e.g. for jarsigning or other further processing. I ended up using assembly to handle the merge. After some wrangling, I got it to work. The process and sample build.sbt is on my blog.
Related
I am attempting to add a CefSharp control to an AnyCPU project. I have followed the instructions here: https://github.com/cefsharp/CefSharp/issues/1714 and I thought I had everything working correctly. I pushed my changes to to SVN and then checked out a clean copy.
The first time I attempted to build using that clean copy, I received this error:
error MC3074: The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. Line 18 Position 14.
as a result of this error, several other libraries fail to compile. If I attempt to build again, everything compiles fine.
I ran a diagnostic build, and, it appears that the CefSharp packages are in fact being installed from NuGet prior to this error and, the error occurs during MarkupCompilePass1.
This seems very, very similar to this issue: https://github.com/dotnet/project-system/issues/4158, however, in that case, it sounds as if the problem was resolved by switching from package.config to PackageReference, but, that approach did not seem to fix my error.
I have read https://www.xavierdecoster.com/post/2014/03/06/migrate-away-from-msbuild-based-nuget-package-restore.html as amaintland suggested in the issue I mentioned above, and, unless I'm misunderstanding, it's not a solution that I can use. For the time being, out continuous integration runs on CruiseControl (which isn't mentioned as a tool that supports automatic package restore out of the box), and we're stuck on VS 2013.
Right now the only option that I can find that seems like it might work is checking the NuGet packages into SVN. This is a last resort solution for me, but, lacking a better option, I don't know what to do.
If anyone has any insights or suggested steps, I would really appreciate the advice.
I just started to work on a large project that uses SBT for building. I got a new computer with Java 8 installed, but the rest of the team still uses Java 7. That's not a problem as far as the code goes because we're all set to generate v7 byte-code.
The problems arise when attempting to publishing the project using the publishLocal action. Please keep in mind though that I am very new to SBT and some things I say/assume may not be accurate.
We use sbt 0.13. When I run the command sbt publishLocal, it runs the doc action, which in turn runs javadoc to generate the documentation. Since I have java 1.8 installed, it uses the corresponding version of javadoc, which let's be honest is a real pain in the neck, complaining about every single missing #return or #param, self-closing elements (e.g. "<p/>") and such, and returning a non-zero value because of this, thus making the publication fail. However, as I mentioned, the project is fairly big and, although it would be better to complete the javadoc documentation, it's not feasible at the moment.
Luckily, javadoc 8 provides an option do disable the pedantry: -Xdoclint:none will make it quiet about pretty much anything, allowing me to run the publish action by adding it to the javacOptions.
However, as I said, the other team members are still using java 7, and, unfortunately, javadoc 7 does not support that option, so if I push the build.sbt file with this option it will fail on other machines.
So now I'm wondering what I can do. The way I see it, there's a number of options, none of which seems "simple enough" to fix that stupid problem:
downgrade locally to java 7 (not a big fan of having two concurrent versions lying around)
have all other team members upgrade to java 8 (pain for them)
fix all javadoc problems in the whole project (pain for everyone)
Hopefully, there's another option I'm missing that would allow me, for instance, to set the javadoc options based on the java version? Or anything else that doesn't require touching anything else than the build.sbt file...
Thanks!
David
Yes, you can set the Javadoc options based on the Java version:
javacOptions in Compile ++=
sys.props("java.version").split('.') match {
case Array("1", n, _*) if n.toInt <= 7 =>
Seq()
case _ =>
Seq("-Xdoclint:none")
}
So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
I want to obtain the assembly version from my solution and apply that to a cc.net label. I think I'm doing it backwards since all the info out there have the CI server set the version. But I'm not sure how to integrate different release versions and the development branch into CI. Every time we release we up the revision number. Would/should I add a new project in cc.net for every branch? Is there a way to automatically get the latest branch? Sorry for so many different questions in one...question. I'm new to this CI stuff.
FinalBuilder and the AssemblyInfo Updater
[Update : Cool, can't add hyperlinks. Put FinalBuilder and 3xw en dotcom in the end in front of the following url:)
/Products/FinalBuilder/FeatureMatrix/FeaturesCompilerActions/tabid/98/Default.aspx
Use "PropertySet Define" based on .NET Assembly Numbers
Use "PropertySet Load"
Use "PropertySet Incremement"
Use "AssemblyInfo Updater" to save it again
And you're done. :)
You will find this all much easier if you switch to TeamCity. I've wrestled with so many nant scripts/cruisecontrol config files in the past I'm almost blind from angle brackets.
I cried like the accountant who was shown the first spreadsheet program when I started messing with TeamCity. It will make your life 1000% easier.
What are the strategies for versioning of a web application/ website?
I notice that here in the Beta there is an svn revision number in the footer and that's ideal for an application that uses svn over one repository. But what if you use externals or a different source control application that versions separate files?
It seems easy for a Desktop app, but I can't seem to find a suitable way of versioning for an asp.net web application.
NB I'm not sure that I have been totally clear with my question.
What I want to know is how to build and auto increment a version number for an asp.net application.
I'm not interested in how to link it with svn.
I think what you are looking for is something like this: How to auto-increment assembly version using a custom MSBuild task. It's a little old but I think it will work.
For my big apps I just use a incrementing version number id (1.0, 1.1, ...) that i store in a comment of the main file (usually index.php).
For just websites I usually just have a revision number (1,2,3,...).
I have a tendency to stick with basic integers at first (1,2,3), moving onto rational numbers (2.1, 3.13) when things get bigger...
Tried using fruit at one point, that works well for a small office. Oh, the 'banana' release? looks over in the corner "yeah... that's getting pretty old now..."
Unfortunately, confusion started to set in when the development team grew, is it an Orange, or Mandarin, or Tangelo? It looks ok. What do you mean "rotten on the inside?"
... but in all honesty. Setup a separate repository as a master, development goes on in various repositories. For every scheduled release everything is checked into the master repository so that you can quickly roll back when something goes wrong.
(I'm assuming dev/test/production are all separate servers, and dev is never allowed to touch production or the master repository....)
I maintain a system of web applications with various components that live in separate SVN repos. To be able to version track the system as a whole, I have another SVN repo which contains all other repos as external references. It also contains install / setup script(s) to deploy the whole thing. With that setup, the SVN revision number of the "metarepository" could possibly be used for versioning the complete system.
In another case, I include the SVN revision via SVN keywords in a class file that serves no other purpose (to avoid the risk of keyword substitution breaking my code). The class in that file contains a string variable that is manipulated by SVN and parsed by a class method.
An inconvenience with both approaches is that the revision number is not automatically updated by changes in the externals (approach 1) or the rest of the code (approach 2).
During internal development, I'm using milestone numbers (M1, M2, M3...). After release, I'll probably just update dates ("the January 2009 update").