I have updated my check_mk from 1.6.x to 2.0.x
My custom omd-plugins got messed up and so I started to refactor them for the new 2.0 API with the help of this article.
However, when the time for testing came, I got this:
OMD[my_omd]:~$ cmk --detect-plugins=my_plugin -vI my_host.my_company.de
Error in plugin file /omd/sites/my_omd/local/share/check_mk/checks/my_plugin: "'__name__' not in globals"
I was using sym-links.
For source-control, I have a git-repo. I had put sym-links pointing from the old checks-directory back to the plugin-file in that repo. Starting through the above mentioned guide, I created a new sym-link from the new local/lib/check_mk/base/plugins/agent_based/. Adding the required .py suffix in the process. So now I have 2 sym-links pointing to one piece of code, which I had modified in-place.
Turns out: If you do not delete the plugin from the old location, you will always test the old plugin. With sym-links, you will test the new code in the old environment, giving you that error.
Notice the path in the error-message!
As for the __name__ error itself: It seems to come from doing relative imports import .something. Notice the leading dot. It means "in the same directory as this file". Somehow the old environment was not able to cope with that.
I am following the steps of this page:
https://learn.microsoft.com/en-us/composer/how-to-create-custom-actions
and have reached to the part where it is required to merge the two schemas: bots and your custom one. However when running the powershell script found inside the created project template (CoreAssistant template) I have the following error:
Error conflicting definitions of HelpDialog.dialog :
C:\Users\user\source\repos\AvanadeCoreAssistant\AvanadeCoreAssistant\dialogs\imported\Microsoft.Bot.Components.HelpAndCancel\HelpDialog\HelpDialog.dialog
Microsoft.Bot.Components.HelpAndCancel:
C:\Users\user.nuget\packages\microsoft.bot.components.helpandcancel\1.1.2\exported\HelpDialog\HelpDialog.dialog
Error conflicting definitions of HelpDialog.en-us.lu.dialog :
C:\Users\user\source\repos\AvanadeCoreAssistant\AvanadeCoreAssistant\dialogs\imported\Microsoft.Bot.Components.HelpAndCancel\HelpDialog\recognizers\HelpDialog.en-us.lu.dialog
Microsoft.Bot.Components.HelpAndCancel:
C:\Users\user.nuget\packages\microsoft.bot.components.helpandcancel\1.1.2\exported\HelpDialog\recognizers\HelpDialog.en-us.lu.dialog
Error conflicting definitions of HelpDialog.lu.dialog
HelpDialog is a predefined dialog that was already present. I have installed NodeJs and #botframework-cli package because it was required from the powershell script in order to run bf dialog:merge and now it seems these two sources have some kind of conflict.
To add to other answers, changes that worked for me are as follows:
update-schema.ps1, line 11, change "!**/generated" to "!../generated" and add "!../dialogs/imported"
Also, make sure that your custom action project is INSIDE of your bot directory, it should be a folder next to the "schemas" folder for the script to find it.
Note/Edit: Having the project nested inside the bot works to get the script working, though I do not recommend it due to causing other errors. Oddly, I found it was best to move the whole custom solution up a level, next to the bot project. You may have to edit the [botName].sln file in notepad to reference the location of the project, as well as editing the bot project's project reference.
I fixed it by changing the script. I noticed the script was trying to ignore the folder imported and generated but the error message indicated it was not doing so. So I changed it from !**/generated to !../generated.
I experienced the same issue.
To fix this problem you could simply delete the corresponding dialogs in the "imported" folder. Note that this will, however, delete these dialogs in your bot, which is not optimal but should be of little concern for a sample application.
I have a VS2012 solution, containing 10 projects, and suddenly, I can no longer publish my Services project to any folder.
When I try to publish to D:\temp, I get this error:
The expression "[System.IO.Path]::GetFullPath(obj\Release%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528Prod%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529\)" cannot be evaluated. The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
Huh ?
VS2012 (with update 4) seems to have taken my configuration name "Release(Prod)" and completely messed it up, causing the GetFullPath to produce too long a path name.
How the heck can I fix this ?
Out of desperation, I tried to build and publish the same project in VS2013 - and it had the same error message.
One of my colleagues said he'd seen the same thing, but had fixed it by removing the spaces from his configuration name. I tried this, which is why my configuration name is now "Release(Prod)" rather than "Release (Prod)", but it made no difference.
I did also open the file which this error is suggesting is the cause of the error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
..and noticed that there's something in there concerning the AnyCPU platform name. I have tried getting my Services project to use "AnyCPU" and "Any CPU" (depressed sigh) but neither seems to make any difference.
<PropertyGroup Condition=" '$(IntermediateOutputPath)' == '' ">
<IntermediateOutputPath Condition=" '$(PlatformName)' == 'AnyCPU' Or '$(PlatformName)' == ''">$(BaseIntermediateOutputPath)$(Configuration)\</IntermediateOutputPath>
. . .
</PropertyGroup>
Has anyone else seen this issue ?
(A little bit later..)
This is so odd (and frustrating).
My Solution has 5 configurations - the default Debug and Release ones, plus extra configurations for Test, PreProduction and Production environments.
If I select any of these three configurations containing brackets, I get this ridiculous "The specified path is too long" error, as VS2012 corrupts the pathname (as shown in my first screenshot above).
I can't help wondering... is this some kind of VS2012 bug, handling spaces or brackets in the configuration name ?
I can deploy to a path directly with (, (, )) in the Target Location on tyhe Connection tab when publishing to the file system (i.e. not building a path from the configuration name) - but that is not a solution to targeting different locations based on the Configuration.
If you want to keep special characters in the configuration name, but specify a path to the deployment folder that will not cause and issue this post might help: Visual Studio: How to properly build and specify the configurations and platforms for x64 and x86
Specifically play with the settings in here:
In the project properties page, select the various permutations of
Debug/Release and x86/x64 in the solution dropdowns. Make sure the
target processor is set correctly (it should be, but I found instances
when they were not, probably because of my previous attempts). Also,
set the output directory. That should be okay and automatic
(/bin/x86/Debug, etc.). If not, fix.
Looking at what is actually seems to be going on is also potentially useful:
Looking at the numbers inserted:
%25 is an encoded %,
%28 is an encoded (
%29 is an encoded )
Looking at the path:
obj\Release%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***28***Prod%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***29***)
What I think is happening:
So that seems like a good clue that these are being URL or XML encoded. What appears to be happening is that the ( is being encoded as %28 and then the % is being recursively encoded as %25 - generating an infinite %252525252525252525....
A more interesting question is actually why it stops creating 25's from the %'s with this bug (both times it stops creating 25's at 214 characters including the % and the 28 / 29 - not a very interesting number).
Looking at the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets you reference - it makes sense that these strings are being encoded for XML. I would say this is definitely a bug... I have no suggestions for a fix.
Well, I'm going to accept Matthew's answer as the "Accepted Answer".
Thank you for your help.
This is a really odd problem though, and I'm amazed no one else has reported this elsewhere.
Summary of problem (in case Microsoft is interested, or if anyone tries to Google this issue in the coming years)
With a configuration name of "Release (Prod)", I could happily build my code, run it locally, but when I tried to publish it, even to a local drive, I'd get this message:
It's an odd exception, because the Build did create the "obj\Release (Prod)" folder, without any issues. It's just the Publish which seemed to be looking in the wrong place for it.
Following the advice given in this thread, today I attempted to create a new configuration, with the same settings, but without a space in the name: "Release(SecondProd)". Look what happens:
Interestingly, despite this error, it did create a new configuration with this name.
Anyway, I recreated a new configuration, called it ReleaseProduction, and it worked fine.
Of course, I needed to create new "web.config" Transformation for this name, as this doesn't get automatically copied when you create a new configuration based on an old one.
One last thought (just to confuse matters worse !)
When I posted this plea-for-help, the Services project in my Solution refused to publish to a local drive, but my web site would publish okay.
Today, two days since I last attempted a website Publish, I found that the website also now produces the same GetFullPath exception. Nothing's changed ! We use TFS, I have done a file compare with my project files today against two days ago, and they're identical !
It's a really bizarre bug in VS2012 & VS2013.
Btw, this solution & the projects in it, were originally a VS2010 project. They were upgraded to VS2012 over a year ago, but this Publish problem only started happening recently. I'm not sure if the problem is related to using upgraded VS projects.
Again, thanks for your help.
Now I have some Test, PreProd & Production configurations to recreate !
Maybe I'll grab a beer first..
Summarizing and completing Matthew's answer:
Cause: You have configurations with chars that require URI-encoding - in your case, '(' and ')'.
Workaround: Rename those configs.
What happens: Presumably web deploy URI-encodes the path, replacing % => %25, ( => %28, ) => %29. It does so over and over:
obj\Release(Prod)
obj\Release%28Prod%29
obj\Release%2528Prod%2529
obj\Release%252528Prod%252529
...
Until the path exceeds MAX_PATH=260.
I ran into the same thing and all though it does not resolve the issue I found that if I switch the solution configuration away from a build containing "(" or ")"
Then use the appropriate build in the publish dialog it will not error out.
Does anyone have any example of how to use modification reader task?
Ok, I use this over XML:
<modificationReader>
<filename>mods.xml</filename>
<path>path/to/my/file/</path>
</modificationReader>
then, what? How do I get the information in "mods.xml" and use it?
Thanks
This appears to be used with the modificationWriter task which writes the modifications to a file (in the artifact directory by default).
http://build.sharpdevelop.net/ccnet/doc/CCNET/Modification%20Writer%20Task.html
If you're just trying to read in the modifications in to a different projects' buildLog, the above - with a path to the first project - should be sufficient.
Are you trying to do something different?
CruiseControl.NET: Build subproject obtained by SVN
I have an app that has been running fine on the iPhone simulator for some time. Recently, I decided I wanted to re-use the data model and related classes in another project - so I dragged them from this project window to the other then told Xcode not to copy, just to make references. At first this didn't work so I jumped through a number of hoops to try to fix it (I may be asking more about that in another post). After all this, I re-compiled and tried to run the original app -- and it's not working any more. On further investigation, I discovered that when I re-compile the original app, I end up with a bundle that contains a .momd package but it contains only a Versioninfo.plist file - no .mom file, no .omo file like I'm expecting to see. I don't recall making any changes to the original app. I don't get any warnings. I just get an incomplete .momd package (and, not surprisingly, my app now crashes).
What's going on here?
BTW, the app now crashes with this message:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
Which I get when executing this line of code:
self.productRegistry = [[UIManagedDocument alloc] initWithFileURL:self.productRegistryURL];
I figured this out by looking more closely at the file locations in the project directory using Finder. In the Xcode window, everything looks normal but in the actual project directory I found that the .datamodeld package had ended up at the top level of the project directory -- at the same level as the project package itself. Xcode apparently did not like this but unfortunately it did not complain -- it just created a partial build output. Once I moved the .datamodeld package into the same folder as the rest of the project's code, everything worked just fine.
This would appear to be just a quirk. I would expect that Xcode would either see that all is well and build correctly OR it would see that things weren't quite as they should be and fail. In this case, it did not build correctly but was silent about it.
Hope this answer helps someone else someday.