We have recently switched from Weblogic 12 to 14 and in WL 12 we were using JRebel by setting Java Options in WebLogic startup bat file e.g:
set REBEL_HOME=%VIEW_HOME%\...\jrebel5
if exist "%VIEW_HOME%\...\jrebel5\jrebel.jar" set REBEL_HOME=%VIEW_HOME%\...\jrebel5
if exist %REBEL_HOME%\jrebel.jar (
set JAVA_OPTIONS=-noverify -javaagent:%REBEL_HOME%\jrebel.jar -DAPP_HOME=%APP_HOME% %JAVA_OPTIONS%
set JAVA_OPTIONS=-Drebel.log=true !JAVA_OPTIONS!
set JAVA_OPTIONS=-Drebel.metro_plugin=true !JAVA_OPTIONS!
)
But now since we are starting the WebLogic via maven and it is added as a dependency in pom, so I can't find a way to activate the JRebel for our application.
Any help will be appreciated.
To activate JRebel standalone you have two options, either to use the activation wizard or to use the command line tool.
You can start the activation utility by running activate-gui.sh script in a *nix environment. When using Windows, run activate-gui.cmd. The JRebel Activation wizard will open. This window contains two tabs – Try JRebel for FREE and I already have a license.
Additionally, the bin directory contains a script that can be used for license activation via the command line, i.e. in headless environment. To activate from command line, start the activation utility by running activate.sh script in *nix environment or activate.cmd in Windows environment.
$> ./activate.sh <file>|<URL>|<activation-code>|<email>
Specifying the user email is required when activating with a license server URL
You can find more instructions on how to activate standalone applications from the JRebel manual: https://manuals.jrebel.com/jrebel/standalone/activate.html
If you have any other questions, then I recommend contacting our support at support-rebel#perforce.com
Related
I need a single exe-file on a windows pc executing a .Net WPF program. This file must be signed with a code authentication certificat. With this certificat the exe-file is executed on foreign windows system without system warnings or administration rights after copy deployment by user to a trusted place.
I can do this with VS2019 and .Net 4.7.2. But I want go forward to VS2022 and .Net 6.0. Below a simple sample working with VS2019. You can step over signtool, because in VS 2022 already fails the posibility to create a single exe files. Same happens with VS 2019 and .Net 5.0 already in the past, but I find some post with information that single exe-file with WPF first work in future with .Net 6.0. Now, after release of .Net 6.0 and VS2022 I try it again. More options in deployment assistent for single file are available, but nothing creates a single exe-file!
Working process in VS2019:
I create WPF-App (.Net Framework) WPF4Test using .Net Framework 4.7.2
I put code sign command ("C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" sign /a /n "my company name" /t http://timestamp.comodoca.com/authenticode $(TargetPath)) in postbuild step
I build release and enter password of certificate during sign process
bin\Release folder contains 3 files (WPF4Test.exe, WPF4Test.exe.config, WPF4Test.pdb)
I copy WPF4Test.exe to share folder and application is executable and signed
I test process in VS2022 with .Net 6
I create WPF-Application WPF6Test using .Net 6.0
I deploy Application in a folder (in assistant i must select folder twice) (default set configuration Release and destination runtime portable)
pubxml is created and i publish application
deployment folder contains 5 files (WPF6Test.deps.json, WPF6Test.dll, WPF6Test.exe, WPF6Test.pdb, WPF6Test.runtimeconfig.json)
I copy WPF6Test.exe to share folder, but application not start without error message
If I copy the whole folder to share and application run.
I can delete WPF6Test.deps.json and WPF6Test.pdb, but i need 3 files (WPF6Test.dll, WPF6Test.exe, WPF6Test.runtimeconfig.json).
I go back to VS2022 and add additional pubxml file with changed profil option (deploment mode independent, create single file, activate compile ready to run).
But now I get 7 files (D3DCompiler_47_cor3.dll, PenImc_cor3.dll, PresentationNative_cor3.dll, vcruntime140_cor3.dll, WPF6Test.exe, WPF6Test.pdb, wpfgfx_cor3.dll).
What do I have to do to get a single exe file?
How I can sign this exe file during publishing process?
You need to set 'IncludeAllContentForSelfExtract' in the project file or if you using the CLI to build 'IncludeNativeLibrariesForSelfExtract'.
Even if you tick or set single exe if you are producing a self contained exe it will not including the native libraries.
Project File (your-project.csproj)
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
.Net CLI
dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true --self-contained true
Edit your publish profile settings,
Select Deployment mode as Framework-dependent
Select the target runtime to something other than Portable (Produce single file is not available for Portable)
Under File Publish options, select Produce single file
Save the profile settings and try publishing again.
This should produce a single exe file.
If you select the Deployment mode as Self-Contained or independent, it will produce 7 files as you mentioned.
Hope this helps for publishing to a single file!
I want to set up a workflow that allows me to have a git repository with a uniform/consistent formatting. The developers (approx. 30) should be able to commit properly formatted changes to their local repository easily, independent of their operating system (either some Linux or Windows 10) and independent from their IDE. Changes shall be pushed to a Linux server which administrates the remote repository.
From my point of view there are two steps necessary to ensure that the remote repository is properly formatted:
Format the current state of repository according to a set of rules.
Format the files affected by every new commit according to these rules.
The first step can be implemented easily by running an auto-formatting tool (e.g. clang-format) on the complete repository. The implementation of the second step can be further divided into two substeps:
2a) Client side: Format a commit properly before pushing it to the server.
2b) Server side: Check if the repository will be properly formatted after the changes of the commit are applied.
The second substep (2b) can be implemented easily (simlar to step 1). However, the implementation of the first substep (2a) is more demanding and I would like to reach out to the community for tipps/tricks/ideas.
So far I've had a closer look on the Eclipse autoformatter and clang-format:
The Eclipse autoformatter can only be used when Eclipse is installed, I haven't found a Eclipse autoformatter standalone application. Is it possible to run the eclipse autoformatter from the command line without a GUI?
clang-format is a unix tool which I cannot install and run standalone on a windows system. I've seen there is a LLVM executable for windows but I am not sure if the installation will inflict any undesired changes to my system. Is anybody using LLVM/clang-format on windows?
Are there other auto-formatting tools for C which work on Linux and Windows 10? Is anybody successfully using python scripts for this purpose?
I have Teamcity currently setup to run a batch file, this batch file executes a fortify scan. It seems the environment variable 'PATH' had loaded correctly on one attempt and started to perform the scan. On the next build attempt the batch file couldn't locate one of the executable(sourceanalyzer.exe). When looking into the user defined parameters it seems different environment variables were loaded than the previous build attempt. It looks like the system environment variables load on the successful attempt and then a users environment variable loaded on the failed attempt. Is there a way to permanently set the environment variable PATH in the agent to load only the system environment variables?
UPDATE:
I have tried several things, to include passing in a Fortify environment variable, which does allow TeamCity to start running the scan. However, it looks like I hit another snag with Fortify's plugin for vs2015. The new error states it cannot find the plugin. I assume this is because pathways are hard coded? Seeing as TeamCity doesn't use the System environment variables and I have to pass them in for TeamCity to find these directories. Is there an easier way to use the batch file to load the system environment variables to avoid hard coding pathways? Would setlocal in the batch file help load these system environment variables, so I can just call sourceanalyzer with out creating environment variables or hard coding pathways?
IIRC, Teamcity will ask you if you want to install the build agent on the System account or the user account. By default it selects the System account and as long as you aren't running any GUI apps, you won't notice the difference... until something like this happens. If Fortify is GUI based, then reinstall your build agent on the user account and ignore the following. Otherwise...
When you set your PATH variables using the System(Control Panel) advanced settings, there are two panes, one for user and one for system. Here you can inspect the System variables to make sure they are correct.
What I will generally do is create a new key, say FORTIFY_PATHand prepend %FORTIFY_PATH% to the System PATH variable. THEN RESTART YOUR MACHINE. The path won't get updated correctly until you do.
Next, login to the system account using PSExec: https://superuser.com/a/596395 and try to run your tools from that command prompt to verify that they are working in the build agent's environment. I once had trouble getting an SVN script to upload until I logged into the System account and provided my SVN password. Some settings are stored in %APPDATA% which is different from the user account.
If you can't get Fortify to run from the System command prompt, then you should probably reinstall your build agent to your user account. Or install Fortify to the System account (if possible).
When configuring TeamCity build agents, check the agent system and environment variables By going to Agents->Agent->Agent Parameters, or the /agentDetails.html?id=1&tab=agentParameters&kind=envpath on your server.
After changing the parameters, restart the agent or restart the agent's machine.
Ok, I'm out of my element but here goes anyway.
I need to do a silent install of a vendor supplied windows program. The vendor supplied an MSI file to use with the install. I created a bat file to run msiexec that contains the following line:
msiexec /i "C:\archibussilent\afm\ARCHIBUS 19.msi" /L*V C:\archibussilent\log\msi_SETUP.log
When I execute the bat file an error dialog pops up that says:
"This installation cannot be run by directly launching the MSI package. You must run setup.exe"
and the msiexe error log says:
MSI (c) (80:B0) [15:48:02:588]: Note: 1: 1729
MSI (c) (80:B0) [15:48:02:589]: Product: ARCHIBUS 19 -- Configuration failed.
MSI (c) (80:B0) [15:48:02:590]: Windows Installer reconfigured the product. Product Name: ARCHIBUS 19. Product Version: 19.3.30032.003. Product Language: 1033. Manufacturer: ARCHIBUS, Inc.. Reconfiguration success or error status: 1603.
The error # is 1603 which implies a permissions problem but I've checked the access privileges and don't see any problem.
Is it true that I can't run msiexe without running Setup.exe?
Any help is appreciated - Thanks.
The "you must run setup.exe" is a vendor authored requirement not specific to MSI in general. They may have had a good reason for it or they may have just authored it as a gate check to not have to test other scenarios.
You'll have to edit the MSI with ORCA and look at the LaunchCondition and InstallExecuteSequence tables to figure out how they implemented. Then you can create a transform to bypass the check or possible pass a property in such as SETUPEXEDRIVEN=1 to simulate being called from setup.exe. (One particularly large and well known installer development product passes this into their MSI when you create a setup.exe with it.)
The setup.exe may be serving a purpose. For example it might be authored with a manifest requiring elevation or it might be downloading and installing prerequisites or possible making sure the MSI is cached in a given location for future installation transactions.
Also I assume you want to add a /QB or /QN to make the install go silent. You'll like also need to have already elevated the cmd session prior to calling since MSI doesn't support UAC prompts when installing silently.
This is most likely an Installscript MSI file made using Installshield. This is a non-standard MSI file featuring more advanced GUI and a few other advantages. In my opinion this is a particularly problematic type of setup due to a few serious bugs without suitable workarounds. I consistently recommend this project type to never be used. It is especially problematic for corporate deployment.
These setups feature a number of command line parameters for the setup.exe file. As Chris states you can probably run it via a transform and set the property SETUPEXEDRIVEN=1 and you may try to use setup.exe /a to run an admin install (More info: purpose of an admin install). This will extract all cab files (if any) from the MSI and put the files on a "network installation location" for use in corporate networks - essentially a smaller MSI with the setup files next to it. I have seen setups that then will allow to be run directly from the MSI - just give that a shot too.
As to the reason why these setups require setup.exe to launch:
In prior editions of Installshield the Installscript language runtime had to be installed prior to launching an Installscript based MSI. This appears to no longer be the case since Installscript is now run without a runtime.
The setup.exe is there to install any updates to the Windows Installer Engine (msiexec.exe), and for that to be possible a setup.exe launcher is needed. Such an update is rarely required, and should today be done via Windows Update.
A number of legacy features, such as being able to access the Internet (!) via the setup.exe (highly undesirable for corporate use), download runtimes and components and extract temporary files are also done via the setup.exe.
And there are other features too, most of which are undesirable for corporate deployment.
Here is a previous answer from me on a similar issue featuring a link to a PDF with actual sample command lines.
I have a simple Windows Form application(WPF) with entity framework. After compiled, only a few files generated:
EntityFramework.dll
EntityFramework.xml
MyApp.exe
MyApp.application
MyApp.exe.config
...
Then I just copy following files to a network shared folder:
EntityFramework.dll
MyApp.exe
MyApp.exe.config
Then I can double click on MyApp.exe from developer computer the launch the app, but can not launch from another end user computer.
How to resolve this problem?
When you double click, app is not launching means certainly it is crashing so type the command eventvwr in run or cmd it'll open the Event viewer in that go to Windows Logs and Click on Application, you can see different levels of logs in that just find the last error log view the details it might help you
Have a look in the event log on the target computer and look at the error that is actually being reported.
It could be a missing installation of the correct version of the DotNet framework as suggested in the comments above, or it could also be that the execution policy of the target computer is preventing the user from running from a network drive (As a developer you probably have admin rights on your local pc allowing you to do this).
Whatever the actual cause you are always better to use some form of installer, rather than this form of putting files on the network (commonly known as xcopy deployment).
Probably the best solution is to use Visual studio to generate you a click once installer and publish it to your network drive. This will then copy the application locally on the users pc and run it from there.