I downloaded and installed OpenWrap, since allegedly it was the best way to get binaries for OpenRasta. But when I try to run o add-wrap openrasta-full, OpenWrap gives me this error:
Package openrasta-full not found in repositories.
Just to cover my bases, I also tried o add-wrap openrasta-devtools, since that's the command that's specifically given as an example on the OpenWrap homepage. It just gave me the same error (with the different package name, of course).
When I installed OpenWrap (o.exe) from openwrap.org, and ran it the first time, I got a console window asking if I wanted to install, and I chose the "install and add to the path" option. It chugged for several minutes, downloading packages, but then the console window closed, so I don't know if the "install" completed successfully. Now when I try to re-run the file I downloaded, I just get an error: "The term 'o' is not a recognized command or alias. Check the spelling or enter 'get-help' to get a list of available commands." So apparently it's the same EXE and self-installs, so I have no way to re-run the install or even tell whether it was successful.
How can I troubleshoot this and get OpenRasta installed?
So there was some issues with the 2.1 packages that all should have been resolved now.
To create an OpenRasta site you can:
OpenWrap 1.0
With 1.0, you need to first create a new project
c:\src> o init-wrap myProject
c:\src> cd myProject
Then create a new asp.net site (or console app or whatever you want). You then need to hook up OpenWrap to your project.
c:\src\myProject> o init-wrap -all
And finally add the OpenRasta packages to your project.
c:\src\myProject> o add-wrap openrasta-full
OpenWrap 2.0
If you're using OpenWrap 2.0, it's a bit easier.
First, install the devtools on your system.
c:\src> o add-wrap openrasta-devtools -system
Then initialize a new project
c:\src> o init-wrap myProject
c:\src> cd myProject
And create a new OpenRasta site using
c:\src\myProject> o new-OpenRastaSite mySolutionName My.Base.Namespace
This will use the default templates to create an OpenRasta site.
As OpenWrap 2.0 gets more functionality around templating, I'll probably make the openwrap creation implicit (if you're not within an OpenWrap project, the templates will create one) and more options available in the template (hosting type for example).
Related
I'm trying to compile the SvnQuery project (https://github.com/kalyptorisk/svnquery.git) with the a version SharpSVN.dll which I created on my PC, but I keep seeing the error message CS0400: The type or namespace name 'SharpSvn' could not be found in the global namespace (are you missing an assembly reference?).
Using the SharpSVN.dll which comes with the SvnQuery source code, I do not see this error message, nor any other.
Both SharpSVN.dll files look the same when I open them in .NET Reflector, but there is one difference - the file which I created doesn't have version information. (To be exact: When you look at the file's properties in File Explorer, "File version" and "Product version" are empty.)
I followed these steps to create SharpSVN.dll:
Check out from https://ctf.open.collab.net/svn/repos/sharpsvn (tried trunk and the 1.1200x branch). Open VisualStudio command prompt (tried 2012, 2015 and 2017), cd to 'imports' folder, run 'nant build'. Result: no errors, but this doesn't create SharpSVN.dll (and I guess it shouldn't).
Now double-click SharpSvn.sln in the src folder. This opens VS2017. Compile Release|x86. Result: no errors, many warnings, SharpSVN.dll (with no version information) created in src\SharpSvn\bin\Win32\Release.
Any ideas about this issue?
Thanks...
I found the solution. My problem has nothing to do with the missing version number. In fact, I had compiled SharpSVN for a .NET version higher than that of the SvnQuery project. After increasing the .NET version number for SvnQuery and related projects, all compiled well. And SvnIndex.exe seems to run smoothly (test still ongoing).
We use VS 2017 and consume NuGet packages the old way. We do not use PackageReference as of yet.
When a NuGet package reference is updated through the NuGet Manager in VS, the respective assembly binding redirect is not updated automatically - we have to do it manually.
So, I suppose it is up to the package to take care of it through the tools\install.ps1 script. Now, I think I know how to implement it, but I do not want to invent the wheel. Surely the code already exists somewhere, but where?
Clarification
Our application is strongly signed and it targets .NET 4.5.2 currently (soon to be upgraded to 4.7.2). We use packages.config.
I need to explain what is going on. There are three players on the field:
A tool - DbUpgrade
The tool plugin Api - DbUpgradeApi
An implementation of the plugin Api - LogDbUpgradeProgress
Let us inspect the DbUpgradeApi package. 3 versions of it are relevant to us:
The version against which LogDbUpgradeProgress is compiled - A
The version against which DbUpgrade is compiled - B
The latest version of DbUpgradeApi - C
The DbUpgrade tool loads the plugin LogDbUpgradeProgress at runtime. The binding redirects are needed, because A is not the same as B (and because the code is signed, nothing to do here currently)
If C is higher than B, then we should update the reference to DbUpgradeApi in DbUpgrade. But doing so must be accompanied with updating the binding redirect. And this is the essence of this question.
Ok, so I just spent the last hour testing, and I didn't need to do anything that I consider special for binding redirects to work.
But first, are you sure you need binding redirects? .NET Core doesn't need it. If you're using .NET Framework, but with a project using PackageReference, then it's resolved at build time, your app.config doesn't need the binding redirect in the version that's checked in with your code, but when you build and check the [your exe name].config file it does have the binding redirects. Also, binding redirects only matter when your assembly has strong naming. If you didn't sign your assembly, then binding redirect isn't needed.
Here are the steps that I took to create a reproduction of getting binding redirects in a console app using packages.config.
Create an empty folder to start with. I used dotnet new sln, dotnet net nugetconfig to generate a new sln and nuget.config file. I edited the nuget.config file to add the folder localFeed as a source, and set the globalPackagesFolder to gpf so I didn't pollute my real global packages folder with test packages. Also created a strong name key with sn -k snk.snk.
Create first test classlib. dotnet new classlib -n someLib. I edited Class1.cs to change the class name to SomeClass and added a property that retusns the value "Version 1". Used Visual Studio to set snk.snk as the signing key. dotnet pack to generate V1 of the package. I then edited SomeClass to change the message to "Version 2" and then ran dotnet pack /p:version=2.0.0. Finally, used nuget.exe add -source localFeed someLib\bin\Debug\someLib.1.0.0.nupkg and again for v2 of the nupkg.
Create the second test classlib, dotnet new classlib -n anotherLib and set the signing key to snk.snk. Changed Class1.cs to AnotherClass and added a property public string Message => new someLib.SomeClass().Message;. Added a reference to someLib version 1 in the csproj, then built, packed and used nuget.exe to add the nupkg to localFeed.
Opened Visual Studio and created a .NET Framework console app. Added a reference to anotherLib, which automatically brought in v1 of someLib. Upgraded the reference of someLib to v2, and confirmed that packages.config now has a binding redirect for someLib.
Created another .NET Framework console app and did the same as step 3, but this time using PackageReference instead of packages.config. The project app.config doesn't have binding redirects, but the .config file in the bin folder after build does.
edit: perhaps an important part to understanding NuGet/MSBuild binding redirect behaviour is the following: In both steps 3 and 4, if I add a reference only to anotherLib, then no binding redirect is created because all assembles that reference someLib reference the same version. Only by making my console app reference a different version of someLib than anotherLib uses, then the binding redirect is created.
In an app with plugins, the building the app assembly won't have a binding redirect, because it's the only assembly in the compile command line that uses the plugin contract dll, so no conflict to need a binding redirect. When the plugin assembly is built, only the plugin depends on the plugin contract dll, so again no conflict so no binding redirect. If you copy all the dlls into a single folder, then there can be a conflict in the required version, but this is a deployment time issue, not a build/compile time issue, so build tools may not help. One way to resolve this would be to add a reference to the plugin project from the app assembly. This way at compile time the build tools can see that two different versions of the plugin contract dll is used, so a binding redirect can be created. This only works if you build the app assembly. If the app is just a binary that you're given, then changing the binding redirects becomes a deployment time responsibility, so development/build tools may not help.
I'm using latest Jenkins (v 1.590) LOL, but Jenkins official site say: 1.588. I'm 200% sure that I did see 1.589 and 1.590 few days back on Jenkins official download site(when I wanted to upgrade Jenkins to newer version).
This is what I see at the bottom of my Jenkins instance page.
Page generated: Nov 19, 2014 12:07:51 PMREST APIJenkins ver. 1.590
Now, the issue I'm facing is: Since I upgraded few of the plugins and Jenkins itself recently, some of the jobs are missing (I see this can happen during upgrades but upgrading to latest Jenkins should fix it and I'm two steps ahead of what Jenkins has on their official site, right):
I go to Manage Jenkins, Manage Plugins, Go to Available tab, check mark bunch of plugins to install (Artifactory, Maven project plugin etc ) and restart Jenkins using Jenkins GUI interface (which happens automatically once plugins are downloaded/installed in Jenkins GUI). After the restart, I do the same to see whether the plugin is now showing under "Installed" tab or not, but to my luck, it's still showing under "Available tab" and is NOT listed under "Installed" tab. If I open an existing job's configuration OR create a new job, the features available due to installed plugins are NOT visible i.e. if I installed Maven Project Plugin, I don't see an option to create a Maven style(2/3) project job while creating a new job.
I see valid .jpi files for respective plugins in plugins folder in JENKINS_HOME and there are some .pinned files as well. I have tried this a couple of times but the plugins are not visible once installed. Installation doesn't give any error during the whole operation.
Jenkins system log file (upon Jenkins restart) is attached (NOTE: Use slow download button to see/download this log file).
Download at SpeedyShare
or
[code]http://speedy.sh/x6vd8/Jenkins.System.Log[/code]
Issue was with the plugins permissions and expanded folders.
If you see under the plugins folder, you'll see .jpi or .hpi files (Jenkins jpi and Hudson hpi).
If I have awesomeplugin.jpi then there will be a folder called awesomeplugin.
Using Slav's hint, I ran bunch of checks and found out of 70+ plugins that I had installed, few of them somehow got "root" and "root" as their owner and group for their .jpi files and corresponding folder.
Now, The best solution one can try (the safest approach) is to chown -R yourvalidjenkinsuser:yourvalidgroup * and chmod -R 755 * as root. Before doing this, stop/shutdown jenkins.
I went even a step further, I first took backup of config files / whole jenkins JENKINS_HOME folder. Then I went to plugins folder and remove all .jpi corresponding folders using root account or as the owner of those folders (NOTE, I didn't delete the .jpi files). Then, I ran the above two commands (chown/chmod) and started Jenkins.
OUTCOME:
when I'm going to Jenkins > New item (to create a new job), Shenzi, all different types of jobs options are showing up (which included the Maven2/3 type job which I found got missing and few others like "Multi-configuration project" and Multijob Project job type.. all were missing and now they are showing up.
OK, I also checked one of the old job, went to its job's configuration and Shenzi!! I now see all the features there i.e. (Promoted Job plugin feature "Promtoe builds when.." check box. This feature which I configured sometime back, got missing but now it's showing up again.
Few of the Maven jobs that I created in past with Maven Release Plugin and Release Plugin POC work had bunch of steps in it. I found there was nothing in the Build step (after this whole mess), but after the above solution, I now see everything is back. I can see the configurations and build steps populated as they were set.
I hope this can help someone facing similar issue.
Still, I don't know why my Jenkins version is 1.590 (which Jenkins updated recently in automatic fashion) and Jenkins site today says, their latest Jenkins artifact is version 1.588 (seems like a mystery).
When you say "valid .hpi files", did you actually test that they are valid? You should be able to rename them to .zip and extract as a valid archive. An issue I face a lot is the network layer filtering system that we have in the office. It intercepts Jenkins's calls sometimes with the filtering system's login page, instead of whatever internet resource was being loaded.
If your .hpi files are not valid zip archives, open them in a text editor, and see if they are in the form of an html page/response of some kind.
My aim is to have package restore working on a build server so that I don't have to check in binaries. At the moment, I'm simply trying to get it to work on my own machine using Visual Studio.
Here's what I've done so far:
Followed the instructions here http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, including both setting the Tools-Options flag and the environment variable (belt and braces)
Installed the NuGetEnablePackageRestore package as suggested here NuGet package restore consent without NuGet
Checked everything in (the .nuget solution folder and its contents), but not the binaries I want to reference, because that's the whole point of the exercise
Here's what I'm doing:
Check out solution
Verify that nunit.framework.dll and moq.dll are not present in the checked out solution
Build the solution
Visual Studio complains that Moq is missing. I search for the dlls in the solution directory and find that:
nunit.framework.dll is present in the appropriate bin folders
Moq.dll is nowhere to be found
But there's more. This is truly mysterious, but if I do a fresh checkout, disconnect from the internet and build, I get precisely the same results - nunit.framework.dll is there, but moq.dll is not. The build process has conjured nunit.framework.dll literally from nowhere.
So it's something of an understatement to say that I am completely baffled. Can anyone suggest answers to the following questions:
Why is package restore not downloading Moq?
Where on earth is the build process getting nunit.framework.dll, if not the internet?
In vs, Options, Package Manager... there's a section "Package Cache", if you click on the "Browse" button it will take you to the location of the nuget cache in your machine.
Okay, I noticed in the documentation that enabling package restore was supposed to modify project files in order to add a new target. My project files did not have this change. Right-clicking the solution title in VS and selecting 'Manage NuGet packages...' then added the required changes and everything built as it should.
I checked, and package restore still appears to work when I have no internet access, so I'm still mystified about that. Does NuGet maintain some kind of cache of binaries outside the solution?
I have started to try to use StatET and Texlipse with a view to producing SWEAVE reports. When starting the R console in the StatET plug-in for Eclipse (OS X 10.6.4), I get the message:
[INFO] The R package 'rj' is not available, R-StatET tools cannot be initialized.
Information on http://www.walware.de/goto/statet states:
"The package only works in the default R Console (RJ) in StatET. Therefore you have to install and update it using the command line":
R CMD INSTALL --no-test-load rj_*.tar.gz
What does this mean exactly?
In Eclipse under "Install new Software" and the site
WalWare - http://download.walware.de/eclipse-3.6
it states that
RJ Core Library 0.5.0.b201008271600sw
is already installed.
Any helpful guidance gratefully received.
[rant] I also lack the reputation to put my response where it belongs. And there's no button there indicating this. Just a big screen full of nowhere desired to click upon. Negative discoverability sucks. It sucks in Eclipse and it sucks here, too. [/rant]
I'm finding rj frustrating under Ubuntu. On my system, with each major Ubuntu upgrade with a new version of R, I have to go through this procedure over again.
One time I tried to use a tilde (~) character in a path name within some Eclipse configuration field. This failed silently.
My current configuration is as follows. In my ~/.Renviron file:
R_LIBS_USER=~/etc/R/amd64/2.11
Once rJava works, there is an rJava directory here. Just so I don't drive myself insane, in ~/etc/R/README I put a note that my current R configuration is controlled by ~/.Renviron
Somehow at one point I ended up with permission problems where
R CMD javareconf
was failing. Once in frustration I foolishly ran this under sudo to work around this problem, and ended up with permission problems on the generated files. Stupid! The correct fix was to make all the files in /etc/R world readable. Maybe javareconf is only important if you mess with your default Java. Previously, I was running the Sun's JRE. Since 10.10 I'm running icedtea6 and it seems to be working OK. One time it was just the thing to make my configuration work again.
Once I have the right Java binding, from command line R:
install.packages("rJava")
I've had file permission problems running this in the past. I think it was fixed by making all files in /etc/R world readable.
The following is a useful diagnostic to see if this worked, from within any R console:
> system.file("jri",package="rJava")
[1] "/home/allan/etc/R/amd64/2.11/rJava/jri"
If it doesn't look right under Eclipse, there is also some startup debugging available, though it took forever before I noticed this in the docs at StatET.
I created an R Console run configuration for R 2.11 debug In the JRE tab add -Dde.walware.rj.verbose=true. In the Common tab, click Allocate additional Error Log Consoles.
The main configuration options are as follows. Main tab, Launch Type: RJ. R_Config tab, you need to select a Configured R Installation, or create/edit one if you don't have one that works. Mine is Name=R, Location=/usr/lib64/R In the Environment tab I have R_LIBS_USER=/home/USER/etc/R/amd64/2.11 according to how I set things up above. Do not use the tilde (~) character here!
If you end up mucking about with this problem as much as I did, you end up killing a lot of dead consoles. In the Main tab I added the program option --no-save. I don't think this does anything, since I can't end my console by pressing CTRL-D. In the R_Console tab, I added the following R snippet:
q <- function(save = "no", status = 0, runLast = TRUE){
.Internal(quit(save, status, runLast))
#<environment: namespace:base>
}
This gets rid of the annoying "save workspace" prompt when killing an R console with the red square (is that symbolic?) My current workspace also includes a C project, so my R console constantly comes up underneath a blank C-Build console. Annoying as all hell! Haven't solved that yet, but I did discover that from within a StatET code windows the keybinding CTRL-R C pulls the R console to the top.
With my R 2.11 debug configuration I get an extra console titled /usr/lib/jvm/java-6-openjdk/bin/java. You'll have to spelunk the console drop-down to find it. The following is a pertinent snippet of a successful initialization:
CONFIG: JR library path:
/home/allan/etc/R/amd64/2.11
/usr/local/lib64/R/site-library
/usr/lib64/R/library
10-Dec-2010 7:56:47 AM org.rosuda.rj.JRClassLoader addClassPath
FINE: Added '/home/allan/etc/R/amd64/2.11/rJava/java' to classpath of URL loader
A lot more spoo, then finally:
10-Dec-2010 7:56:48 AM de.walware.rj.server.jriImpl.RosudaJRIServer start
INFO: R engine started successfully. New Client-State: 'Connected'.
Looks good, right? But lo and behold in the R console:
[INFO] The R package 'rj' is not available, R-StatET tools cannot be initialized.
Ignore the lying bastard! Turns out my rj is working just fine. No idea why this failure message persists.
Every time around the block with this problem some new amazing piece of gravel ends up in my sneaker.
I don't know whether I've covered everything, but I've written enough for now. Maybe if there are comments I'll come back and fill in the blanks.
Note: found an Eclipse plugin for console switching by keyboard here: Eclipse: Keyboard shortcut for switching between consoles?
It looks like you need to install the RJ library which can be downloaded from the StatET site here: http://download.walware.de/rj/rj_0.5.0-5.tar.gz (more recent versions of RJ can be found at http://www.walware.de/it/downloads/rj.mframe)
If you save that file on your desktop, you can then load it into R with the command they provided R CMD INSTALL --no-test-load rj_*.tar.gz after navigating to your desktop or wherever you saved the library file. Alternatively, you MAY be able to use the GUI interface and select Install packages from local ZIP files under Packages in R, though I haven't used R on a Mac so the layout may be slightly different.
After installing rj with in the R console using
install.packages(c("rj", "rj.gd"), repos="http://download.walware.de/rj-1.1")
(See http://www.walware.de/?page=/it/statet/troubleshooting.mframe for the correct rj version),
do not forget to update the R_LIBS variable in Eclipse (Windows -> Preferences -> StatET -> Run/Debug -> R Environments -> Edit). To find out the value just type in the R console:
packageDescription("rj").
In my windows 8 installation this returns C:/Users/Fibonacci.PYTHAGORAS/Documents/R/win-library/3.0/rj/Meta/package.rds. The value of R_LIBS I set to
C:/Users/Fibonacci.PYTHAGORAS/Documents/R/win-library/3.0
which is the path where all libraries are installed.
As stated in http://www.walware.de/?page=/it/statet/troubleshooting.mframe newer versions (Versions > 0.5.5) do not need the R CMD INSTALL etc... command.
Here the quite similar I had and the solution I found.
I originally installed Statet using the Eclipse built-in tool "Install new software ...."
I seems it downloaded Statet + rj and that the installation process went well.
After this first installation, I tried to install both packages again. Eclipse refused reading that they already are installed. And, both packages/programs were actually listed in the window of Eclipse.
But, the R console still refused to launch, the dialog box reading that I had to check whether rj was available and that the file paths were correct. Another strange thing was that window explorer had been unable to locate rj on my disk.
???
To solve my whole problem, I simply downloaded rj from http://www.walware.de/ and installed this package via the r console and using the basic install.packages() command.
It now works perfectly .
But, I still don't understand everything ..... :-)
I'd make a comment but I lack the necessary reputation. For Windows, the procedure is the same. There's no zip file. Use the tar.gz. Worked for me. The command, working from the same folder as the downloaded file:
$ G:\R-2.12.0\bin\i386\R.exe CMD INSTALL --no-test-load rj_*.tar.gz
The project is now hosted on GitLab, see
https://gitlab.com/walware/de.walware.rj-server.gr/-/wikis/Installation.
To install:
install.packages(c("rj", "rj.gd"), repos="https://download.walware.de/rj-4.0")
Note that binary packages are available for Windows.
As explained in this message from Stephan Wahlbrink on 2022-02-03 announcing StatET 4.5 release, this version works with R 3.6 to 4.1, and RJ-4.0.
For current information on StatET, check the home page and especially the news.