In theory, given that Azure now includes go support by default, I should be able to run:
go get github.com/etsy/hound/cmds/...
and have Azure pull down the necessary files but when I run that I get the following:
D:\home\site\wwwroot
'go' is not recognized as an internal or external command,
operable program or batch file.
If I cd to d:\program files\go\1.7\bin and run it again I get:
D:\Program Files\Go\1.7\bin
go: cannot find GOROOT directory: c:\go
Is this simply a limitation of Azure web apps?
Thanks,
Alex.
After you install Go Lang for Azure Websites, please restart the site to make it available and you need to ensure Go binaries (found in D:\home\site\wwwroot\go\bin) are in Path system environment variables. You could add a folder to the PATH through an XDT Transform.
<environmentVariables xdt:Transform="InsertIfMissing">
<add name="PATH" value="D:\home\site\wwwroot\go\bin" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
</environmentVariables>
Besides, as far as I know, you should also add GOROOT and GOPATH to environment variables.
Related
I'm following this guide to create a web app with a custom deploy.cmd file. The article suggests that I can get a copy of the current deploy.cmd file (which I'll then modify) using the following command:
azure site deploymentscript --python
Unfortunately, when I install the Azure CLI using the MSI linked in the article, there is no azure binary on my path. I do have az -- is this a newer version of the same CLI? -- but I can't find an equivalent deployment script generation command for that executable.
I found a deploy.cmd file using Kudu (under D:\home\site\deployments\tools) but am not sure if that's the appropriate file to use. Can anyone suggest the right Azure CLI command for deployment script generation, or confirm that the deploy.cmd file I found is the right one to modify? Thanks in advance!
Based on my knowledge, there is not an equivalent to azure site deploymentscript in azure cli(2.0). So, you could not do deploy custom script with Azure CLI 2.0.
You had better know the difference between Azure cli 2.0(az) with Azure cli 1.0(azure).
Azure CLI 2.0: Our next-generation CLI written in Python, for use with
the Resource Manager deployment model.
Azure CLI 1.0: Our CLI written in Node.js, for use with both the
classic and Resource Managerdeployment models.
For your scenario, if you could install Azure ClI 1.0, you could refer to this link to install Azure CLI 1.0.
Instead of using the command line to generate a starter deployment script, there is an alternative approach that is often easier:
Deploy your repo without any deployment scripts.
Go to the site's Kudu Console.
From the Tools menu, choose 'Download deployment script'. You'll get a zip with a .deployment and deploy.cmd files.
Commit both files at the root of your repo
Tweak them as needed
More information please refer to this link.
You can use kuduscript to generate the deployment script.
npm install -g kuduscript
kuduscript --python
Here is the list of options
Options:
-h, --help output usage information
-V, --version output the version number
-r, --repositoryRoot [dir path] The root path for the repository (default: .)
--aspWAP <projectFilePath> Create a deployment script for .NET web application, specify the project file path
--aspNetCore <projectFilePath> Create a deployment script for ASP.NET Core web application, specify the project file path
--aspWebSite Create a deployment script for basic website
--go Create a deployment script for Go website
--node Create a deployment script for node.js website
--ruby Create a deployment script for ruby website
--php Create a deployment script for php website
--python Create a deployment script for python website
--functionApp [projectFilePath] Create a deployment script for function App, specify the project file path if using msbuild
--basic Create a deployment script for any other website
--dotNetConsole <projectFilePath> Create a deployment script for .NET console application, specify the project file path
-s, --solutionFile <file path> The solution file path (sln)
-p, --sitePath <directory path> The path to the site being deployed (default: same as repositoryRoot)
-t, --scriptType <batch|bash|posh> The script output type (default: batch)
-o, --outputPath <output path> The path to output generated script (default: same as repository root)
-y, --suppressPrompt Suppresses prompting to confirm you want to overwrite an existing destination file.
--no-dot-deployment Do not generate the .deployment file.
--no-solution Do not require a solution file path (only for --aspWAP otherwise ignored).
My source code for Hybris (custom extensions) are in a GIT Repository but my Hybris platform binaries are in another folder. (I am a newbie to hybris)
How to set my build path in this case?
Say if my custom extension folders are under (TFS Git Repository)
C:\HybrisCommerce
Whereas my Platform binaries
C:\HybrisBinary\Bin\Platform
C:\HybrisBinary\Config
C:\HybrisBinary\data\
C:\HybrisBinary\log\
How to configure Build Path in such a case?
You can create a Windows symlink to link your custom extensions folder to your hybris project folder.
Here is an example. I am not sure if it will work exactly for your system so you may have to modify it.
mklink /J "C:\HybrisCommerce" "C:\HybrisBinary\Bin\custom"
This way, the default hybris build will search for its extension in bin/custom, which will actually point to you git repository.
For eclipse, you can just add all the projects into the workspace. General > Existing Project into Workspace First all project from you hybris folder and after that all your custom projects from the git repository folder. Important! Keep in mind, that eclipse will change the .project file of your custom extensions. Don't commit this file to git repository, because you might break the other team members projects.
Good luck!
You can simply create symbolic link as suggested by #Hristo Staykov
Or
Modify localextenstion.xml as below, to target all your custom extenstions (Taken from GIT/SVN) by giving full path (dir).
e.g. <extension dir='C:\HybrisCommerce\custmocore' />
Then configure your Eclipse for hybris e-commerce using these steps
Go to your Local Hybris setup,reach this location:
[LOCAL_Path]\hybris\config\
Open the localextensions.xml,you will see something like this in the file:
<path dir='[PUT_YOUR_CUSTOM_LOCATION_PATH HERE]' autoload='false' />
Then add all the extension name(that needs to be included from custom/default here) right below it:
<extension name='abc' />
<extension name='xyz' />
<extension name='efg' />
Save it and Run ant clean all.
I'm tring to build a .NET Core solution in a Docker container but cannot get the dotnet restore command to work. I need to use both a local network share (just a simple filesystem repository) as well as the official nuget repo.
My nuget config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="Nuget Feed" value="https://api.nuget.org/v3/index.json" />
<add key="custom feed" value="//uvd-fs1.uvd.local/Install/UVPackages" />
</packageSources>
</configuration>
I start the container using the command docker run -it --rm -v "$pwd\:/sln" microsoft/aspnetcore-build:latest
Then cd sln and dotnet restore ./UVAudit.sln.
This produces the following error:
/usr/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error : Failed to retrieve information about 'RavenDB.Client' from remote source '/uvd-fs1.uvd.local/Install/UVPackages'. [/sln/UVAudit.sln]
I would expect the RavenDB package to be restored from the official feed, but if I remove the custom package source from the nuget.config file, only the non-official packages cannot be resolved. This makes me think that the error message is a bit misleading. I would also think that the /uvd-fs1.uvd.local/Install/UVPackages part should in fact be //uvd-fs1.uvd.local/Install/UVPackages, but adding further slashes does nothing. Any ideas if I'm doing something wrong or this looks like a bug? I'm no Linux expert, so I might be missing some basic concept.
I also tried changing the repository path to smb://uvd-fs1.uvd.local/Install/UVPackages which caused the error message to change to:
/usr/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error : Failed to verify the root directory of local source 'smb://uvd-fs1.uvd.local/Install/UVPackages'. [/sln/UVAudit.sln]
/usr/share/dotnet/sdk/1.0.1/NuGet.targets(97,5): error : smb://uvd-fs1.uvd.local/Install/UVPackages [/sln/UVAudit.sln]
I don't really know if this even makes sense to try, just one of the very limited clues provided by googling.
UNC paths (\\..) are primarily a windows concept. While the underlying protocol for network und paths is smb, the NuGet client won't support it - the reason it works on windows is because the file system api handles UNC paths transparently.
If you want to restore reliably from a docker container, i suggest setting up a NuGet feed (there is a NuGet.Server nuget package for asp.net websites which is sufficient for small internal feeds).
I have a startup task to install sql xml 3.0 sp3 but this not work.
In my project i have a folder "setup" which contains two files, setup.cmd and sqlxml.msi. In setup.cmd i have the following script:
start /w msiexec /i sqlxml.msi /qn
And in my servicedefinition:
<Task commandLine="setup\setup.cmd" executionContext="elevated" taskType="simple" />
Make sure the files are actually being deployed. In Visual Studio, open their properties and make sure Copy to Output Directory is set to "Copy always". If in doubt, extract your deployment package to a directory (it is a ZIP file) and see if the files are there.
When setup.cmd runs, the current directory will be your web application's bin folder so make sure to use a CD setup command inside setup.cmd.
Follow the debugging tips mentioned in Windows Azure Startup Tasks: Tips, Tricks, and Gotchas.
I was wondering, if I deploy a WSP using the stsadm command:
stsadm -o addsolution –filename myWSP.wsp
Will this also install the required DLL's (already included in the WSP) into the GAC?
Or is this another manual process?
This is determined by the DeploymentTarget attribute in the solution's manifest.xml. If you are maintaining this file yourself, using the following syntax will deploy the code to the GAC:
<Assemblies>
<Assembly DeploymentTarget="GlobalAssemblyCache"
Location="MyGAC.dll" />
</Assemblies>
If you are using a tool to create the solution, it depends on the tool. WSPBuilder defaults to deploying to the GAC however it can be configured otherwise. See the "Scoping the assembly for BIN instead of GAC (including Code Access Security generation)" section of this article by Tobias Zimmergren for steps on how to deploy to bin.
If you're building the packages via VS, open the Package and click the Advanced tab on the bottom. You'll be able to add additional assemblies and specify the Deployment Target from here. I'd strongly recommend doing this rather than updating the XML directly...but that's just me.
As the command says addsolution it is just going to add the solution to the Solution store. You need to call the command deploysolution to get the stuffs to place. Here is the command that you need to call
stsadmin -o deploysolution -name [solutionname] -allowgacdeployment
Note that allowgacdeployment is mandatory to place the files to gac. you can more help on this command with this
STSADM.EXE -help deploysolution
There is an alternate option to get this done,through UI. Go to Central Admin -> Operations ->Solution management select the solution and say deploy. this will be easier way to get it done quick.