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
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 have a nuget package which has .dlls files that it automatically copies to a directory when the program is compiled. Is there a way to specify where the dlls files will be copied to?
I know it's possible to modify the .targets file of the package but assume I don't have access to the package. The project is managed through git so I'd rather not have to distribute binaries along with the licenses included in the package. Currently when someone downloads/compiles the source, the nuget package is automatically downloaded through nuget restore. Is there a way to override the .targets file of the package?
I'd prefer not to use scripts to manage the dll files if possible. Also this is for a C++ project and I know nuget has restrictions based on the languages used.
If your question is asking if there's a simple configuration file or something similar where you can write "copy contents of package X to location Y", then no.
To most people, the difference between the various components in the build system are not important, so it doesn't matter to them if NuGet copies something or their project's SDK copies something, or MSBuild copies something. However, since you're now trying to do something more advanced, these differences may be important. NuGet only writes/copies files at restore (and therefore only to the packages folder, not the project output folder), but after restore, NuGet doesn't run at all. NuGet just makes the files known to the rest of the build system, and those components are responsible for deciding what to do. For example, where to copy files.
Since both C++ and .NET projects use MSBuild, the same debugging techniques can be used. From a "developer command prompt", build your project using the -bl switch to generate a "msbuild.binlog" file. You can open this file with the MSBuild structured log viewer. You can then use the search to find where in the build each dll is copied, and what the copy arguments (including destination) is. You can also look to find where the item that defined the file to be copied was created. Then, you can write an MSBuild target in your project file (or another file that gets imported by your project file) that runs at an appropriate time and updates the item to set the destination you want the file to be copied to. But, MSBuild is a scripting language, and you said you didn't want to write a script, so you might not like this approach. And if you're not already knowledgeable about MSBuild scripting, it's probably more effort than writing a powershell script. But at least it would happen automatically as part of the build (and therefore happen when you build and debug in Visual Studio), and not be some other process that needs to be manually run.
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 have a home machine and office machine I use to publish websites using Visual Studio 2013. If I make a change from the same machine, and re-publish, just the changes are published, not all files.
However, when using my clone machine at the office, even if I do a get latest, make one small change, and re-publish, all files are published, not just the ones that changed, and not just the ones that have been recompiled. ALL dll files, even third party dlls that have not changed or have been recompiled with a new date, are republished. Same thing happens if my cohort publishes a small change on his machine after I did the last publish. Not a problem if publishing twice from the same machine as then only the changed files are published.
Is there anyway to prevent complete republishing just because a different machine is used to publish than the one used for the last publish? Thanks.
This seems to make "Determining Changes" a lot slower, but for .Net 4.5 [and
up(?)], use this info from:
https://msdn.microsoft.com/en-us/library/ee942158:
To configure Web Deploy to use checksums instead of dates to determine
which files need to be copied to the server, add the following element
to the .pubxml file (Publish Settings):
<MSDeployUseChecksum>true</MSDeployUseChecksum>
Like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSDeployUseChecksum>true</MSDeployUseChecksum>
<!— other settings omitted to keep the example short -->
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
First of all, I do not understand the behavior of MSBuild+VS2013 and the publishing feature completely as I just started to use the publishing feature myself. I'm looking for a way to speed up publishing via FTP web deploy in VS2013. (I'm not using TFS for a get latest though.)
I would say this is partially explained in a different context at this SO question. The MSBuild process. Timestamps of certain files are being compared and then could indicate MSBuild/VS2013 whether a target (build output) is up-to-date or not. Then files that are not up-to-date are being recompiled.
As you all work on different machines, timestamps are likely to be different quite soon.
To find out what is actually going on during builds/publishes, set build output verbosity to detailed or diagnostic, for a moment:
VS2013 menu - Tools - Options... - Project and solutions - Build and run - output verbosity - set to -> detailed or diagnostic. Run the build, and see the Output panel/tab in VS2013. Select "show output from: Build" to see results if not already visible. Don't forget to set it to the original setting after checking the build details, as it could slow the build down a bit.
But why even unchanged third party dll's are being republished? Possibly because these dll's ARE actually overwritten during a build. You might have the assembly reference property "Copy local" set to true to get your website running without any manual uploads to be done for this. Or you are using a commandline copy command with the overwrite parameter explicitly set to true during project's post build event (like 'copy /y ...' or 'xcopy /y ...'). Then the timestamp of the file that is to be published is overwritten for sure, see in
the "obj\Release\Package\PackageTmp" folder (or for example: "\Debug" instead of "\Release" if Debug build is set for the selected publish profile.)
Furthermore, VS2013 as default does NOT check timestamp differences on the targeted webserver if you are using FTP publishing, at least that is my experience. As for the other publishing options like a web deploy I don't know yet. But the differences you experience seem normal behavior to me, as you run builds on different machines and publishing files from different machines as well. So timestamps are likely to be different... which, again, indicates 'changed' files to be published.
As I'm curious how this question should be solved, I was looking for this in the first place:
Maybe a TFS build server is an option for you, configured with a rolling build. But I read on a specific SO (sorry, can't add more links at this moment as I've just registered) that is suggesting to do clean builds to prevent new problems. And that will force full publishing again as files are all being changed by the clean build... so that won't work I think.
As an answer, you might want to use these FAQ answers on MSDN for web deployments. See the questions:
"Can I exclude specific files or folders from deployment?" .NET 4.0/4.5 and/or
"How to make Web Deploy use file checksums instead of dates to
determine which files were changed?" .NET 4.5 only!
The first option is to exclude files.
The second option is to use a checksum to compare files instead of timestamps, but that could be somewhat slowing the build(?) process, as the FAQ says. Note the first few lines on that FAQ pages, on how you can edit your publishing profile to apply one or both of these elements!
Also it is an option to put the thirdparty dll's in a different project which you then could only include that project in the deploy for a certain solution configuration (VS2013 menu - Build - Configuration Manager, see the checkboxes in the 'deploy' column there for every project. Though I'm not sure if this is part of the VS2013 'publish' feature as a web deployment, because this deploy column checkboxes are greyed out for my solution projects for some reason I don't understand yet... so I can't test it to verify this option.)
Though it sounds logic, don't forget to create backups/copies/screenshots first before you change any settings or publishing profiles, and then change the same settings/configurable files on the other machines you and your colleagues work at.
Using Visual Studio 2012, Azure SDK 2.1, I am trying to figure out the best way to create the csx folder for running in the azure emulator. My understanding is that the csx folder is not created until I package the Azure project. I can create a package manually from Visual Studio, but this is not an option for an automated build. The other option is to create the package using the msbuild command line. This seems a bit heavy handed as it will actually do a build which is more time consuming than just repackaging.
So, I thought that cspack might be a more lightweight option. However, when I call cspack with the following command line:
cspack.exe ServiceDefinition.csdef /copyOnly
I get the error: Need to specify the physical directory for the virtual path 'Web/' of role MyProjWeb.
But, I don't do anything like that when using msbuild. I have read a bunch of things about specifying the physical directory and some of the confusion that it can cause. So, I would prefer not to use it unless absolutely necessary, especially since I don't need to specify this when building from msbuild.
So, my main question is what is msbuild doing that cspack is not doing and how do I do the same with cspack?
My other question is, what is the easiest way to generate the csx folder for testing in the azure emulator?
Edit - Resolution
I thought that I would put down how I resolved this here in case it helps someone else. The big answer to my question (thanks to Chandermani and some other reading) is that CSPack with /copyOnly is basically a fancy xcopy to a folder structure according to some rules. If not using /copyOnly it then also does a fancy zip to create a package. Not complaining, it is fine that it is simple, but it is good to know this at the outset. You can use it for packaging anything for azure it is not tied to what can be built in Visual Studio, e.g. a PHP site. Using msbuild has the added benefit of only copying that files that are part of your web site deployment.
So, what I found when I got CSPack working and pointed at the mvc project folder is that it copied everything including source files. Which is not what I wanted. The solution that I could find is to first package the web site then point CSPack at the packaged files. If you do down this path then this link is very valuable as it describes it step by step.
So, it was either having an msbuild post-step in the Web project to package the files and then a post-step in my Azure project to cspack it or to have an msbuild post-step in my azure project to create the package (do cspack with the benefit of only including my web deployment files). Well, it seemed simpler and less error prone to just to have the one post step and let msbuild do the heavy lifting. So, the post step in my azure project is something like:
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devfabric:shutdown > NUL
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devstore:shutdown > NUL
if $(ConfigurationName) == Debug set CONSTANTSPARAMETER=DEBUG
if $(ConfigurationName) == Release set CONSTANTSPARAMETER=
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe $(ProjectDir)$(ProjectFileName) /t:clean;publish /p:Configuration=$(ConfigurationName) /p:TargetProfile=cloud /p:OutputPath=bin\Cloud$(ConfigurationName) /p:VisualStudioVersion=11.0 /p:overwritereadonlyfiles=true /p:DefineConstants="%CONSTANTSPARAMETER%" /verbosity:minimal /p:PostBuildEvent=
The first two lines shut down the compute and storage emulator.
The next two lines set the preprocessor constants. I found that #if DEBUG was no longer taking effect when built using the msbuild line. I think that this is safety protection that DEBUG is stripped when creating a package. I only ever use the package that is created by an automated build system, so it is safe for me to keep the DEBUG constant.
The actual msbuild line has a number of switches. I'll describe the unusual ones:
/p:PostBuildEvent=
If we don't set the postBuildEvent to empty then the same post step will keep getting called forever. And ever...
/p:VisualStudioVersion=11.0
Those clever guys at Microsoft made it possible to open projects with both Visual Studio 2010 and 2012. Which is great, but can bring great sadness when you run msbuild from the command line and end up with nasty MSB4019 error messages because it is looking in the wrong Visual Studio folder for the Azure tools.
Also, note that that I use the cloud profile. Since I am only after the csx files it doesn't seem to make a difference whether I use local or cloud at this point. When I run in azure I specify ServiceConfiguration.Local.cscfg.
Edit: In the end I took this out of the post step and put in my automated build. My original intention was that running the tests from my dev machine would be the same as my automated build, but the post step took too long and the views were sourced from the obj folder rather than the proj folder when running under the debugger which meant I had to copy across when making changes on the fly.
Unanswered questions
It would still be good to understand how msbuild does things to reduce knowledge friction when dabbling in this area. Does it create a package for the website and pass it to CSPack? Or does it parse the project files and then pass some crazy arguments to CSPack? Also when you run an azure project in the debugger, it runs in the emulator with only the binaries in the csx folder (not the images, etc). How does it do that? It would be great to see some description with pictures of the Azure build pipeline with that showed the lifecycle all the way to deployment. That might also explain why there are two copies of the binaries. Also, this would have been a whole lot easier if Visual studio had a project flag like packageOnBuild for the Azure project with options to do a copyOnly or to create a package. I see no point in uneaten cake. Edit: There is a DeployOnBuild setting that can be added to csproj.
Finally, as I mentioned the whole purpose of this is to get a csx folder that I can point the emulator at so that I can run my unit tests on my dev machine. I do the formal packaging on a build machine so don't really need it in Visual Studio. So, really I don't want to package anything and was hoping that there was an easier way of achieving all this.
Since msbuild uses the the azure project file to perform the build, it can derive a lot of information form the project file.
For cspack, the assumption is the role code has been compiled and is available for packaging. Since cspack does not depend upon project file, it needs a explicit information for the code path of the the web\workerrole project. The csdef file does not contain any such information. I suggest if you want to use cspack. Look at its documentation and try to create a package for emulator deployment from command line (CopyOnly option). Once you find the correct syntax you can embed it in you build script.