When carrying out an update-database in the package manager you have to select a project as the startup project and the output from the command tells you what the startup project it is using. My question is what is the significance of the startup project?
The start-up project is used to find the correct App/Web.config file and the output directory to use.
Consider the following. You're DbContext exists in ClassLibrary1 which is used by WebApplication1. The settings that EF will ultimately use are stored in the Web.config of the WebApplication1 project. When using migrations commands, you would specify ClassLibrary1 as the default project and WebApplication1 as the start-up project. Also, if you were using relative paths somewhere inside your context or migrations, you would want them to resolve relative to WebApplication1's output directory, not ClassLibrary1's.
Of course, if everything is in one project, you don't have to worry about the start-up project since it will always be the same as the default project.
Related
i am using hybris version 2005
I installed addon with this command
ant addoninstall -Daddonnames="notificationaddon" -DaddonStorefront.yacceleratorstorefront="myStorefront"
How can I run adon without using this command on all devices? Where should I add what settings
Afaik there is no need to install an addon on all "devices", the addoninstall call changes two files in the destination extension e.g. the storefront extension:
myStorefront/.classpath
myStorefront/extensioninfo.xml
These files are usually under source control, so if you commit them, every time the project is built there is an ant macro that copies the addon into the extension directory.
Additionally, the addon should be added to the localextensions.xml, usually there is an template for the local dev env and the production, both should be updated.
I understand by devices, you mean the servers? If this is right, then you do not have to run this on servers. Instead, let the CI script take care of this. Based on the deployment strategy, your script would automatically run this command and the addons get installed on the storefront.
Every Addon does different work and requires a different way of inclusion.
The add on has a file project.properties.template that contains the properties that become active once you install the addon.
The addon has build.xml that is used to build that along with the storefront extension, whenever called back.
The source code including the java and XML that gets compiled along with the storefront. An AddOn can override any resource in the storefront extension.
For further information, please visit the Addon Concept illustrated in SAP help portal.
I created some custom modules and Visual Studio drops the build files directly into the Kofax Bin directory. It is important to note that I'm using the modules as Winforms applications and Windows services (at the same time). The generated files are
MyModule.exe
MyModule.exe.config
MyModule.InstallLog
MyModule.InstallState
MyModule.pdb
I think that I only need the .exe file here. Of course I also add the .aex file to the directory to install the module. I also created two batch files to register the module on the local machine
RegAscEx.exe MyModule.aex
pause
and to install the module as a Windows service
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "%~dp0MyModule.exe"
pause
after running them as administrator I can delete them from the directory of course. I would like to know if it should be always fine to provide the .exe file, .aex file and the two batch files (which will be deleted later) only?
Basically correct. Some thoughts:
Build your application using the Release configuration (vs Debug). See discussion here.
PDB files usually are not needed in production. Still, you may want to generate and keep them if you plan on debugging in production.
The app.config file should be kept. Maybe you want to use application settings later on, and the supportedRuntime element is useful if someone wants to run your CM on a machine without that version of .NET framework being present (Windows will show a nice error message)
Keep the AEX file. This is required if someone wants to register your CM on another machine (e.g. deploying from DEV > TEST > PROD).
Include a single batch file that allows registering your CM on a new machine as well as adding it to Kofax Capture. Here's an example:
rem "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" SmartCAP.CM.Sample.dll /codebase /tlb:SmartCAP.CM.Sample.tlb
rem RegAscSc.exe /f Register.inf
Another thing I usually include is the ability to install my CM in a similar fashion to native KC modules, for example: SmartCAP.CM.Sample.exe -install and SmartCAP.CM.Sample.exe -uninstall. Take a look at the AssemblyInstaller class for details.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
When I deploy package to test server, all parameters that are in project scope are not available. (they are all in project.params) file.
Here is how we deploy and run packages?
Prior SSIS 2012, I would have xxx.dtsx and xxx.dtsConfig in folder, then we would have script that uses DTEXEC tool to execute package. Our scheduling tool runs jobs/script hourly, daily, monthly, etc...
Now, with SSIS 2012, they got away with configuration and introduced parameters. Now in my package deployment folder, I have only xxx.dtsx and project.params files. Project.params file contains all variables that I decided to parametrize. While this work nicely when debugging in VS2012, once deployed, it doesn't work at all.
Any advice on what to do here?
Thanks
For non-project based connections, when you run the package, it'd take a form like
dtexec /file MyPackage.dtsx
However, for project based connections, you need to include the project (.ispac) in the dtexec call. Otherwise, you'll end up with missing connection or project parameter errors
dtexec /package MyPackage.dtsx /project MyProject.ispac
I have been working with setting up TeamCity, and I have almost everything working with the exception of being able to compile VS2005 solutions that have referenced assemblies that are outside of the solution path. I have our SVN repository structured as follows
Root
Libraries
Project 1
Trunk
Project 2
Trunk
Project 1 and Project 2 reference third party assemblies located in the Libraries. This works just fine from within the VS2005 IDE and when calling MSBuild on the solution files since the HintPath for all of the references look like this:
..\..\..\Libraries\ThirdParty.dll
The problem I have encountered is that when TeamCity dies the checkout from SVN for Project 1 or Project 2, it places everything into internal directories that don't match the structure of the relative path given by the HintPath.
How do I go about clearing this up, either through a TeamCity configuration or configuring my solutions/directory structure differently? Either one will work for my needs.
Thanks!
If you create a separate VCS root for Libraries, you can use checkout rules to control where the files are placed in the directory structure so that it matches the structure on your local machine.
We set up a network directory with all our third party dlls. Then we mapped the directory to a drive.
That way the dlls weren't a part of our solutions and all projects just call z:\3rdParty\example.dll to get the assemblies.
Someone else on my team actually set up our teamcity, so I could be completely mistaken about how the problem was actually fixed or if we even had that problem initially :)
What i have done is to set the VCS ROOT of the project to the top level directory ("Root" as per your project structure). And detached the default project vcs root created by teamcity. After this you can create a custom build step by specifying your solution here "Solution file path: *" in build type "Visual Studio (sln)". Now it properly handles library references.
There is a drawback here in that, since the vcs root is at the top level, even unrelated check ins could cause your project to build and that may not be suitable for time consuming builds. Don't have a workaround for that yet.