Mod Adoption Tutorial

[linuxgurugamer]

16 minutes ago, HebaruSan said:

No change, still getting the same exception.

That doesn't seem to discuss why this textranslate tool is looking for a file or directory that doesn't exist in the Output folder, or how to get it to appear there. Are there other steps that need to be done before msbuild will work?

Try this:

https://www.thecave.com/2002/10/21/visual-studio-net-problem-envdte-missing-or-not-found/

[HebaruSan]

1 minute ago, linuxgurugamer said:

Try this:

https://www.thecave.com/2002/10/21/visual-studio-net-problem-envdte-missing-or-not-found/

Fails at step 1. "Under the .NET Framework directory C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\ you will find the envdte.dll assembly."

I assume that's because the 3.5 installer won't run?

[linuxgurugamer]

The actual version numbers are probably different, use it as a guide

[HebaruSan]

3 minutes ago, linuxgurugamer said:

The actual version numbers are probably different, use it as a guide

There's no EnvDTE.dll in any of the version folders.

[linuxgurugamer]

Then you need to install more of the VS.  This is beyond me for now, maybe @sarbian or @RoverDude would have a better idea

[HebaruSan]

Found an envdte.dll in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\PublicAssemblies, copied it to Output\KSP-AVC\. Still says "System.IO.FileNotFoundException: Could not find file 'C:\Users\user\github\KSPAddonVersionChecker\Output\KSP-AVC\EnvDTE'."

I'll just submit the PR blind; you can tell me if there are compile errors. I'd rather test it myself, but this isn't like Unix where things can be investigated and fixed.

[linuxgurugamer]

You didn't copy it to the right place.   Look at the last link I posted.

 Copy this file to C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\ and you should be good to go. 

[HebaruSan]

1 hour ago, linuxgurugamer said:

You didn't copy it to the right place.   Look at the last link I posted.

 Copy this file to C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\ and you should be good to go. 

Same exception.

[sarbian]

https://developercommunity.visualstudio.com/content/problem/15434/cannot-find-wrapper-assembly-for-type-library-envd.html

Quote

 This breaking change was introduced in VS 2017 as part of an effort to reduce Visual Studio impact on the system. As part of this, a large number of Visual Studio assemblies are no-longer installed in the GAC. I validated that for both VS 2015 SP3 and VS 2017

• VSIX project templates no-longer use COM references for EnvDTE assemblies
• A project can still add COM references to EnvDTE assemblies and MSBuild 14.0 / 15.0 will use tlbimp to import the assemblies.
• The build error is a limitation of MSBuild 12.0 and below.

Some possible solutions:

• In old VSIX projects: Remove old COM references to EnvDTE, EnvDTE80, EnvDTE90 and EnvDTE100. Add new references using Assemblies | Extensions tab and select EnvDTE, EnvDTE80, EnvDTE90, EnvDTE100. The project should build now.
• Repair Visual Studio 2013 from Add Remove Programs. This should fix the registry entries.

 

[linuxgurugamer]

@HebaruSan see Sarbian’s post above

[HebaruSan]

So if I'm understanding that correctly, this thread's recommended approach and all mods already using it need some updates to be compatible with Visual Studio 2017. That's fine, I'll wait.

[linuxgurugamer]

On 8/8/2018 at 11:07 AM, HebaruSan said:

So if I'm understanding that correctly, this thread's recommended approach and all mods already using it need some updates to be compatible with Visual Studio 2017. That's fine, I'll wait.

@HebaruSan

There is a line in the AssemblyVersion.tt  near the top which looks like this:

<#@ assembly name="EnvDTE" #><# /* This assembly provides access to Visual Studio project properties. */ #>

Delete it, it isn't needed anymore.  This should solve the problem

[HebaruSan]

51 minutes ago, linuxgurugamer said:

@HebaruSan

There is a line in the AssemblyVersion.tt  near the top which looks like this:

<#@ assembly name="EnvDTE" #><# /* This assembly provides access to Visual Studio project properties. */ #>

Delete it, it isn't needed anymore.  This should solve the problem

Thanks, that did it! Hard to believe it was that simple!

Do you want a new PR to fix the syntax error in the last one? Or did you already take care of it?

[linuxgurugamer]

1 minute ago, HebaruSan said:

Thanks, that did it! Hard to believe it was that simple!

Do you want a new PR to fix the syntax error in the last one? Or did you already take care of it?

Yes, I haven't gotten to it yet

[micha]

On 9/3/2018 at 10:28 AM, linuxgurugamer said:

@HebaruSan

There is a line in the AssemblyVersion.tt  near the top which looks like this:

<#@ assembly name="EnvDTE" #><# /* This assembly provides access to Visual Studio project properties. */ #>

Delete it, it isn't needed anymore.  This should solve the problem

THIS!!

Also, I've created a pull-request for StageRecoveryMod for your consideration which has some tweaks to your build environment to make it more generic.

Eg, use of $(DevEnvDir) instead of hard-coding the full path to Visual Studio, and generally making your scripts a little bit more generic by removing hard-coded paths. 

I appreciate you are managing a lot of adopted mods so of course the environment has to first and foremost be easy to use for yourself, but by adopting a few small changes it might make it easier for others to help out with minor contributions and thus reduce your workload a little.

[linuxgurugamer]

10 minutes ago, micha said:

Eg, use of $(DevEnvDir) instead of hard-coding the full path to Visual Studio, and generally making your scripts a little bit more generic by removing hard-coded paths.

With an eye towards making my mods more easily built by others,  I have just spent the last month updating ALL my mods, more than 160 dlls, with this:

$(KSPDIR)\GameData\000_ClickThroughBlocker\Plugins\ClickThroughBlocker.dll

as well as updating all the AssemblyVersion.tt with this:

    // For Visual Studio / MSBuild Build-Time Template Resolution
    string RootDirectory = System.IO.Path.GetDirectoryName(Host.TemplateFile) + @"\..\";

    //
    // Update the following with the name of the .version file which is in the root directory
    //
    string versionfile = RootDirectory + "StageRecovery.version";

I realize that you are eager to help, but I have to keep all my mods consistent, otherwise I would not be able to do this.  I cannot update a single mod to what may be an admirable goal at the expense of incompatibility with my other mods.  Nor do I want to spend time right now to figure out what may or may not be working in my environment.

What would be more useful would be write a document detailing each suggested change.  This way I can more easily understand what it is you are suggesting, and be able to apply those change at my next round of updates.  I cannot make major changes in a way that causes problems.  I need to be able to create a script which I can use to do the updates on a project as I need it.  If you would like to write such a script, I'd be happy to review and possibly use it when the time arises.

Regarding the patches regarding changing  Log.Error to Log.Info, changing the ones in onVesselRecovered is reasonable, although they aren't generating "log spam".  Log Spam is something that writes continually to the log, these functions only write a line to the log when a vessel is recovered.  That's not spam, and can be useful at times whe a log file is submitted for analysis.  Also, the one in the RecoveryControllerWrapper is an error and needs to be reported

[micha]

I made the changes with an eye to be applicable to all of your mods. I just used StageRecovery as a full example for your consideration. The pull request is fairly small and the changes should be self-explanatory enough to hopefully be self-documenting.

Thank you for considering.

EDIT: PS. I answered your points re my pull request in the pull request itself

Edited November 20, 2019 by micha

[linuxgurugamer]

4 minutes ago, micha said:

I made the changes with an eye to be applicable to all of your mods. I just used StageRecovery as a full example for your consideration. The pull request is fairly small and the changes should be self-explanatory enough to hopefully be self-documenting.

Thank you for considering.

I'll say it one more time:  I cannot and will not make an environment change to a single mod.

This is a hobby.  I don't get paid for it.  Thinking about it, I think I've put in somewhere around 40 hours of work just to do the changes I've done.  And every change I make has the possibility of an error.  I think that over the past month I had about 5-6 errors in the updates I put out, which I don't consider to be a bad ratio, an error rate of about 0.625%

I can't accept it in a PR, because that is not repeatable.  The changes would have to be done for every other mod as well.

Write a script, (I prefer bash, but whatever you want) which you can run in the top source directory for one of my mods, which will make all those changes correctly, and I'll consider it.  But I don't have time right now to do more than what I'm doing.

[micha]

Just now, linuxgurugamer said:

I can't accept it in a PR, because that is not repeatable.  The changes would have to be done for every other mod as well.

Apologies for the misunderstanding; I wasn't meaning for the pull request to be used verbatim.  It was my way of documenting my proposed changes. I **know** you are doing this as a hobby and a public service to the community, as are most modders, and that you don't need more unnecessary work.

I was part-way through your suggestion of writing a document, but I'll consider writing a script instead.

Peace.

[linuxgurugamer]

2 minutes ago, micha said:

Apologies for the misunderstanding; I wasn't meaning for the pull request to be used verbatim.  It was my way of documenting my proposed changes. I **know** you are doing this as a hobby and a public service to the community, as are most modders, and that you don't need more unnecessary work.

I was part-way through your suggestion of writing a document, but I'll consider writing a script instead.

Peace.

Sounds good.  As I said, I prefer bash, but perl or python would also be fine.  If you are a real glutten for punishment, you can use batch files

I'm not familiar with PowerShell, but am willing to use that if that's what you write it in.

I look forward to seeing the results