Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on Documentation of Install procedures. #51

Open
bobbytreed opened this issue Jan 16, 2017 · 7 comments
Open

Question on Documentation of Install procedures. #51

bobbytreed opened this issue Jan 16, 2017 · 7 comments

Comments

@bobbytreed
Copy link

After speaking with Don on Friday, I know that the documentation is still in the works, but do you have a rough guide for deploying the solution? Don mentioned that I should reach out to @majst32

@majst32
Copy link
Contributor

majst32 commented Jan 16, 2017

Here's what I have for now. It worked when I installed it @ 2 weeks ago. Remember it's a work in progress :)

Install .net core 1.0 SDK
Install .net 4.5.2 SDK
Install git for Windows – clone tug into <some tug location> 
Reboot
From ISE, cd <some tug location>\tug.Base
Dotnet restore
Dotnet build
cd <some tug location>\tug.Server.Base
Dotnet restore
Dotnet build
cd <some tug location>\tug.Server
Dotnet restore
Dotnet build
cd <some tug location>\tug.Server.Providers\Ps5DscHandler
Dotnet restore
Dotnet build
cd <some tug location>\test\Run-net452-ps5
Iex -command .\tug.cmd

New-NetFirewallRule -Name "Tug Inbound" -DisplayName "Tug Inbound" -Enabled True -Direction Inbound -Protocol TCP -RemoteAddress any -LocalPort 5000

@bobbytreed
Copy link
Author

bobbytreed commented Jan 27, 2017

Is there future development planned to make this an entirely offline installation?

@ebekker
Copy link
Collaborator

ebekker commented Jan 31, 2017

@bobbytreed -- how do you mean? In terms of being able to just download an installation package that you can install separately?

The steps that @majst32 provided were for being able to setup to build the software in your local environment, they are not the way that an end-user would ultimately use to install a Tug server for say production use. We're just very early on in the development cycle so a formal installation process hasn't been developed yet.

@ebekker
Copy link
Collaborator

ebekker commented Jan 31, 2017

@bobbytreed, if you're just interested in getting Tug installed locally to start playing around, please take a look at these steps to install a pre-release bundle that is powered by a set of PowerShell cmdlets which you can tailor for basic operation.

@majst32 is testing this process out right now and has had good luck with it, and I will formally document and release this as one of the first packages shortly. If you go this route, please do provide any feedback on documentation, installation/upgrade process, ease of use and configuration, etc.

@majst32
Copy link
Contributor

majst32 commented Jan 31, 2017

Yes, sorry for the slow response. The instructions provided were the set of down-and-dirty instructions that I did get to work, by no means were they optimized. I just knew they worked. But as @ebekker stated above, the pre-release bundle is the way to go. This wasn't available yet when I wrote the above instructions. While the bundle still requires internet access, the module can be downloaded to a machine that has internet access and then redistributed by whatever means you would distribute other PowerShell modules such as xPSDesiredStateConfiguration. HTH

@Chirishman
Copy link

My two cents, it is still incredibly unclear to me how I'm supposed to step from the version installed using the PowerShell module to using IIS. Also the How To Deploy link in the project wiki doesn't go anywhere.

@ebekker
Copy link
Collaborator

ebekker commented Feb 2, 2018

@Chirishman, I assume you've looked at this README, correct? There is a reference/link there to this explanation of how to configure IIS to proxy for ASP.NET Core 1.x application.

Unfortunately, the existing installation bundle that has been published to the nuget feed is the original ASP.NET Core 1.x code base. That version did not support Kestrel being the direct HTTP interface to an ASP.NET app unless it was operating in a trusted environment (e.g. a private, trusted network).

I'm working on migrating all of the existing code base from .NET Core 1.x to 2.0 right now. I've finished a few of the core libraries already, and then I'll work on building a new bundle and installation module which I'll publish to the PS Gallery. Once the 2.x version is published you can actually operate that version without IIS -- that is a fully supported and sanctioned configuration with the 2.0 version of Kestrel.

However, if you still want or need to front that with IIS, you will still need to follow the directions in that link (just be sure you follow the 2.0 version of the instructions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants