I am new to peoplesoft area and would like to check if we can use Artifactory OR nexus repository server to store the peoplecode binary
i can compile the code using App designer but once we compile the code, need to create the package and store it to artifsctory server.
does it seems logical OR totally wrong assumption/understanding
please suggest
Regards
On its own PeopleSoft does not have version control. It has change control, but that is something different.
However, there are third party solutions on the market that fill this gap: STAT and Phire, to name two.
What you could do, if you don't want another tool with a licence: export your projects to file and check these files into the repository. You can revert to an earlier version by importing the file in App Designer
You can use the Decode Peoplecode project at https://sourceforge.net/projects/decodepcode/files/ to extract the peoplecode source code. You can also use this java project to check the code into a git or subversion repository.
Related
The problem
I have a Qt IFW installer with an online repository, from which users fetch data to install and update the software.
My installer has a "root script" defined in config.xml:
<Installer>
<!-- ... -->
<ControlScript>controllerscript.qs</ControlScript>
</Installer>
Now I want to change the content of controllerscript.qs and deploy it on the online repository.
when a new user installs the software for the first time, it works as expected
when a user updates its software from a previous version using MaintenanceTool.exe, it does not get the update
Possible solution
I realized that when you create the installer, it generates a file named MaintenanceTool.dat which seems to contain controllerscript.qs (+ other things). I managed to manually copy that file and push it to the online repository (inside a package). That way, the maintenance tool is able to see the package update, and correctly gets the new MaintenanceTool.dat. After that, the maintenance tool is indeed using the new code from controllerscript.qs.
Question
Is there another (cleaner) way to achieve that?
If not, is it really safe to provide a manual update to MaintenanceTool.dat? That file contains many other things, so is there a risk to interfere with the rest?
Thanks,
I prepared a symbol package successfully using dotnet pack's --include-symbols and --include-source switches. Now I wonder how to tell Visual Studio to use that package when trying to step into code of the corresponding non-symbol one.
I tried to place the symbol package to a local folder and configuring solution-level nuget.config file to use this folder as a package source. Idea is that there is maybe some name convention that looks for packages like {name}.symbols in all configured packages sources... but that doesn't work.
Oficial docs (especially the older ones) are talking a lot about configuring "Symbol Servers", but if I understand correctly, that's something different and older, right? If I wanted to set-up an internal symbol server, I wouldn't do that through NuGet. (I really don't want to set up an internal symbol server.)
They are also suggesting to push to smbsrc.net, but I can't do that with internal code, obviously. Also, I can't believe there are hard-coded URLs in .NET toolbox.
I didn't find a way to meaningfully use source included by dotnet build.
There are alternatives though:
SourceLink offers a way to configure mapping between source code build paths and HTTP locations. Unfortunately, that does not work for private repositories without a specific support for source control server authentication method. Bitbucket Server, for example, is not yet supported.
You can embed sources directly into PDBs. I will probably go that way.
my client has a simple SQLite DB exposed through an URL (direct download of the DB entire file).
What I have to do is to download the file and then use it in my app: Android and iOS.
I am already able to use the same DB locally: I have a copy of the same file that is online (not updated) in my assets and resource folders and I can use the data in it inside my app. The DB structure won't change; the file is updated every night to reflect the changes in their DB, so only record updates/additions/removals.
Anyone can give me any advice on how to achieve this result?
Since you already have a url of this data file, then you need to separately download this file and save it to local on each platform, and use DependencyService to call the method of each platform in your portable lib.
For the example of using DependencyService, you can refer to Saving and Loading Files.
For the downloading part, you can use some plugins for example like CrossDownloadManager, which may make your work easier.
Or if you want to complement this work in your PCL, you can add a System.Net.Http reference in your PCL, then use HttpClient to download your database file, but you still need to use DependencyService to save this file on different platforms.
So I have been working with the free version of JWrapper for some time now and have been quite pleased with the results; however, I have now purchased a license and would like to use it but I am unable to find the method with which to activate my JWrapper. I do not use the graphical interface version of JWrapper; rather I have created a xml installation file and pass that directly via commandline to JWrapper for building. Is there a special xml tag for specifying the license location? I was unable to find this information on JWrapper's homepage or support docs.
I received an answer from the support team. In order to use the license without using the JWrapperApp gui to build your application you will simply have to have the jwlicense.txt file in the same directory as your jwrapper.jar
After some tests it appears that the jwlicence.txt file must be in the current directory. So the best is to have all the files (jwrapper jar, jwrapper.xml and jwlicence.txt) in the same folder and run the compiler from that folder.
A member of my project team needs to add source code comments to many of his ASP.NET projects to provide better documentation. Some members of the project team recommend that we conduct thorough regression testing if we add any source code comments since there is a remote chance that some of the source code might inadvertently get commented out and cause a change in behavior of the program. We would also then be required to put the application through a management of change procedure and redeploy to our production server.
It seems to me that we should be able to add the the source code comments, recompile the source code, and use something like an md5 (or sha1) hash (using something like fciv) to compare the before and after DLLs to confirm that the source code comments did not impact the compiled version. Testing this concept with a simple console application, I see that the problem is that the hash of the binaries will change if the version of the DLL increments. If I could remove the manifest from the binaries, perhaps I could then conduct an apples to apples comparison of the binaries.
As an additional challenge, these ASP.NET applications use the ASP.NET website compilation model where the code is compiled dynamically (presumably into %SystemRoot%\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder) the first time the site is visited rather than the web application model where all of the project code is compiled into a single assembly in a bin folder.
Any ideas?
hashing of assemblies doesn't work even if the version is made constant, after each compilation a unique guid embedded inside the assembly changes, this creates a different hash each time. Is it possible to change the application so that it is pre compiled?
There is a tool called bitdiffer that will compare assemblies and report any difference. As part of your integration testing you could run the tool against your new build and compare it to the build in production. this would ensure that only assemblies with code changes get released.
There is also a tool called ndepends that has an api for comparing assemblies. It's very cool!
Rohan West's answer (thanks Rohan!) led me to the bitdiffer comments which provided the following solution:
Before adding code comments, re-create the code files from IL using Reflector and the Reflector.FileDisassembler add-in. This will generate a directory of source code files that contains the core source code only without comments.
Add code comments.
Create a second directory of generated source code files using Reflector and the Reflector.FileDisassembler add-in.
Use a differencing tool such as WinMerge to compare the before and after generated source code directories and confirm that the source code comment changes did not change the core code.