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

when running the Template i receive File Not Found Exception #63

Closed
fuzzysb opened this issue May 10, 2017 · 6 comments · Fixed by #64
Closed

when running the Template i receive File Not Found Exception #63

fuzzysb opened this issue May 10, 2017 · 6 comments · Fixed by #64
Assignees
Milestone

Comments

@fuzzysb
Copy link

fuzzysb commented May 10, 2017

So i have tried TemplateB and TemplateA and both have an issue when pressing F5 to build, they both report the following error

System.IO.FileNotFoundException was unhandled
Message: An unhandled exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
Additional information: Could not load file or assembly 'Hspi, Version=1.3.101.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

so this is because the reference dll's are being copied into the
$(ConfigurationName)\bin<AssemblyName without "HSPI_"> folder
as per the fix-output.ps1 script, however the program cannot find these references there. if i move them back to the $(ConfigurationName) folder then all works fine.

why are you moving them? and where are you specifying that that directory is used to locate required references. BTW i am developing on a separate machine to where HS3 is installed and using VS2015 Update 3

@fuzzysb
Copy link
Author

fuzzysb commented May 10, 2017

ok if i look at the App.Config this shows

<probing privatePath="bin\$safeprojectname$"/> </assemblyBinding>

if i manually change this to

<probing privatePath="bin\<MyProjectName>"/> </assemblyBinding>

then the issue goes away, any idea why this needs to be done manually?

@alexdresko
Copy link
Owner

The best way I explain this is with pictures. Here's why I have it set up that way using the BLBackup plugin as an example. Most plugins appear to be configured this way.

This pic shows the BLBackup plugin exe and config located in c:\program files (x86)\homeseer hs3\.

image

If you look at the BLBackup config file, you'll see this:

image

And, of course, there is a corresponding directory for the plugin's assemblies:

image

They do this to avoid naming and versioning conflicts with other plugins that reference similar assemblies.

We really need to figure out why it's not working on your machine. Are you using the latest version of the plugin? Can you zip up your entire solution and attach it here (or send it to me privately at [email protected])? What OS are you using? If you open up a Powershell window, type host, and press enter, what's the version number that appears? What's the full path to the solution on your dev machine? Is your HomeSeer running on Windows or Linux?

It shouldn't matter that you're on VS 2015 or that you're on a separate machine.

@alexdresko alexdresko self-assigned this May 10, 2017
@alexdresko alexdresko added this to the Definitive milestone May 10, 2017
@fuzzysb
Copy link
Author

fuzzysb commented May 10, 2017

I am using the latest vsix file that i found in the gallery according to when i veiw the plugins its v 1.3.101

image

I got that moving the files post build was to match the structure of other HomeSeer plugins i just couldn't see where the new path was being specified until the penny dropped that id was in the .config file. I have managed to get things working by manually editing the file.

however i thought for templates the $safeprojectname$ was supposed to get substituted at the point that the project was created based on the user input?

i am running Windows 10 Anniversary edition fully patched and my Powershell version is Version : 5.1.14393.1066

i'm not 100% bothered, you can close this as i have an acceptable workaround and if anyone else experiences the same issue they will see this issue and figure it out the same way 👍

Good work BTW gets you up an running far quicker than without, especially as Homeseer's SDK info is targeted at VB which i hate and even then the information seems very convoluted.

@alexdresko
Copy link
Owner

@fuzzysb Ahhhhhhhhhhhh! I get what you're saying now. I'll have a fix posted soon.

@oesolberg
Copy link
Contributor

oesolberg commented Oct 26, 2018

This does not seem to work. I have been testing under linux and it seems that we need to change how privatePath is written. Linux does not handle \ well. But Windows seems to be okay with /
So we need to go from
probing privatePath="bin\$safeprojectname$"/>
to
probing privatePath="bin/$safeprojectname$"/>
(From backslash to slash in path naming)

@alexdresko
Copy link
Owner

Thanks for doing the linux testing, @oesolberg. We'll finish tracking this in #96.

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

Successfully merging a pull request may close this issue.

3 participants